Fork me on GitHub

@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 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.

dominicm09:08:48 > 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   ...}}})
and I'm curling this resource with
curl -X GET --header 'requestid: asdf' '' -v
, but I'm still getting a 400 response with the message
{:status 400,
 :errors ([:header {:error {:requestid missing-required-key}}])}


I have a suspicion headers need to be capital.


in the resource schema inside :header, you think it needs to have :REQUESTID (or "REQUESTID") instead of :requestid?


for the note, the request definitely has

{"host" "localhost:3000", "user-agent" "curl/7.54.1", "accept" "*/*", "requestid" "asdf"}
, so it's finding the requestid, it just doesn't seem to like it for validating the schema. Doesn't seem to matter if I change the schema to have a string or a keyword


ok, figured it out. Apparently it does need to be a string, not a keyword, but in order to use a string in the plumatic/schema as a required key, you have to use

{(schema.core/required-key "requestid") String}
, where as for a keyword, the required-key function is completely optional. (related to this issue )


^^^ @dominicm don't know if you're the right person to point this out to, but having this explicitly demonstrated in the manual would probably be really helpful. I'm sure I can't be the only person who's bashed their head against this before.


Yeah, for sure. It's tough to draw a line between teaching schema, and teaching yada. There should probably either be a better message here.


any thoughts on what I'm doing wrong?


hey folks, does yada supports websocket ?


yes it does 🙂