@danielcompton afk right now, are there other security attributes you think yada is missing? Agree on the break. Security is a hard API to think about with breaking changes, if you don't have secure defaults, then the fiddling to make it secure will never happen. Rich actually mentions security as an exception to growth. I'd be tempted to offer a flag for two versions or so to allow people to turn on the old behaviour whilst they make the switch.

I have been thinking about a new yada bundle called 'alpha' which would replace some extensions. This would be a good opportunity to change security defaults. Alpha would be production ready and supported but with the caveat that breaking changes might happen over the next year.

What do you think?

@dominicm I was thinking of SameSite defaulting for cookies https://tools.ietf.org/html/draft-west-first-party-cookies-07 when I wrote that comment

@malcolmsparks seems reasonable, who is the target audience for it though?

I guess it lets you iterate freely?

Is SameSite imemented across browsers now?

Yes, yada needs to iterate towards full http 1.1 and take on clojure.spec and other things. The ext mechanism is to balance breakage avoidance with improvement

@danielcompton I was thinking of looking into SameSite and such too.

@malcolmsparks adoption doesn't matter so much. If it's standardized we should use it.

https://tools.ietf.org/html/draft-west-first-party-cookies-07 > Expires: October 8, 2016 Not looking positive for it being a standard.

@dominicm yes I agree. I suppose I meant is it standardized yet.

Found a more up to date standard link on MDN docs, but that expired December 2016. Don't think it's a good idea to make a default yet.

The alpha in the bundle/namespace will make it possible to adjust as necessary

This idea is explained (very well) by @stuarthalloway in his defn podcast interview

The strict mode of SameSite is really intense. Links essentially clear your cookies.

Gonna lead to some really confusing behaviour for people browsing the web if it's overabused.

How so? (not disagreeing but don't think I understand)

@malcolmsparks if you're logged into Google with a SameSite cookie, and you click on a bookmark to google mail (because you always forget the link!), you won't be logged in.

Another thought: The content-security-policy is fairly light by default. It's hard to actually do a good restriction that applies to all. But a dsl over content-security-policy could be useful. Would be nice to specify: - Disable 3rd party {js,css,images,etc.} - Only load {js,css,images,etc.} from https - Enable common cdns (e.g. google analytics, cloudfront, etc.)

I'm having problems figuring out why :header as a parameter schema isn't working; my code looks like:

(yada/resource {:methods {:get {:parameters {:query  {:id [String]}
                                               :header {:requestid String}}
                                  :produces   ...
                                  :response   ...}}})

curl -X GET --header 'requestid: asdf' '' -v

{:status 400,
 :errors ([:header {:error {:requestid missing-required-key}}])}

any thoughts on what I'm doing wrong?

hey folks, does yada supports websocket ?

yes it does 🙂