@malcolmsparks: did something change between 1.1.45 and 1.2.0 that creates the interceptor-chain for resources?

all my resources that work under 1.1.45 do not get an interceptor-chain under 1.2.0 (and also 1.1.46)

ok, I see the difference

yada 1.2.0 doesn't set an interceptor-chain on resource creation.

but, how is this supposed to work with manipulating the interceptor chain for a set of resources (I walk the bidi routes to update everything that is e.g. under the "/api" endpoint)

hi @stijn - the rationale for the change is that interceptor chains are part of the processing of a web request with respect to a resource - in upcoming versions of yada resources-as-data will be used for other purposes, so the idea of a single interceptor chain doesn't fit with that model

But, the logic still allows you to explicitly add an interceptor chain which the handler will respect.

You'll just have to start with the interceptor chain of your choice (call yada.yada/interceptor-chain with a nil arg), the modify it as you want, then add it to the resource.

If you look in the code in handler.clj, you'll see how interceptor chains are constructed

Point is, they're now part of handler logic rather than resource logic

Sorry about this, it's part of a wider refactoring/refurbishment effort which I've tried hard to keep existing users immune from, but it's not always been easy

(at least I'm trying to improve yada whilst keeping backward compatibility, in the 0.4.3 -> 1.1 transition it was much more 'move fast and break things')

ok, I see

well, then instead of (yada.resource/insert-interceptor yada.security/authenticate (verify-app-existence apps)) when walking the resources, I should just construct the interceptor chain there?

I need some set of resources to manipulate the context before authentication

or is this no longer the preferred way then?

oh, but I can create a ring handler for that entire set of resources (they fall into one bidi path) and give that handler the interceptor-chain it needs?

that doesn't make sense, what I just said 😛

@stijn I ran into the same problem going from 1.1.45 to 1.2.0: https://github.com/thegeez/clj-wiki/blob/master/src/edge/web_server.clj#L49

1.2.0 doesn't seem to report the body schema validation messages anymore. Is this bug/intentional or something specific to my setup maybe? Let me explain: The resource:

:produces     "application/json"
:methods {:post {:parameters {:body {:field s/Bool}}}
                 ...
                 }

Malformed body

{:status 400,
 :error
 {:field (not (instance? java.lang.Boolean "True"))}}

hi @naartjie - I've had a couple of people point this out - the problem is that yada 1.2.0 only declares text/plain as a format it will render errors in. We've had so many issues with application/json errors (when Cheshire can't render something in the error, so generates its own error instead).

I think the best course of action would be to restore the original behaviour, but I don't know what we should do when Cheshire fails

@malcolmsparks I actually prefer the new 1.2.0 way - it makes sense, if you want a JSON response, make it explicit, i.e. in responses. I guess I was just noting it to compare notes and check if I didn't make a mistake with the migration somewhere.

^^^ but I'm not sure how to code that yet, would need to watch for schema validation errors in :responses 400 I guess.

yes, for now. Are you thinking of adopting clojure.spec any time soon?

I would like to yes, but all in due time. I am getting on a bit now, and bleeding edge hurts a lot more than it used to 😜

What is the plan for yada + spec?

I've done a proof-of-concept and considering the move to clojure.spec prior to adding more major features - I'll preserve backward compatibility though

@malcolmsparks if/when you move to clojure.spec will you do something extra to deal with spec's inability to disallow keys ?

i can kinda sorta see why spec doesn't want to deal with disallowing keys, but for validating messages received from the internet i would like to be able to strictly check the schema and forbid anything off piste

@mccraigmccraig is it not enough to do something like: (s/and (s/keys …) #(= (select-keys % [:a :b :c]) %)) ?

@dominicm recursively...

looks like https://github.com/metosin/spec-tools aims to support disallowing extra keys

Yeah, they're doing some crazy stuff in there. I personally feel like this is a problem for the spec community to solve at large.

There are 2 aspects to a possible clojure.spec migration - the first is :parameters, which is where spec-tools is likely to be the library we'll use. The second aspect is the spec of the yada resource (and possibly handler) to help alert to errors by the yada resource author

I think the :parameters section could list a flat list of parameters, each with their own specs, rather than the whole parameters structure having a single spec.

@mccraigmccraig it's a good point you're raising, glad you did

It's the second aspect (validating yada resources) where the clojure.spec policy of allowing unknown keys is quite useful

@malcolmsparks what about a response spec? to communicate the shape of data to the user

@stijn isn't that captured in the Content-Type (and generally media-types)

and JSON Schema

oh, and is there a way to add that to the swagger documentation from yada?

agree @malcolmsparks - allowing unknown keys can be nice for fn/handler/resources... i've done similar with spec quite profitably in the past - although i know of at least one place in my code where not having the ability to disallow extra fn args could lead to some nasty subtle bugs, so i'm a bit ambivalent about the feature/lack-thereof

@malcolmsparks I've got the pages displaying correctly now - it was a rookie error of an incorrect indent! Now, I just need to sort out the consumer on the post and the project will be updated, then I can start on the fun stuff of Swagger and authentication 🙂

Is there a common pattern for making csrf tokens?

There is https://github.com/ring-clojure/ring-anti-forgery

@danielcompton Nothing explicit in yada to help you

Possibly use :properties, and generate the same value to put in your GET response and check in your POST. Same resource.

You could use buddy.jwt to generate a value you can verify.

Without revealing secrets