Fork me on GitHub

Why doesn't this work as expected?

(def api
   ["/about" :about
    "/some" :there])

(match-routes api "/some") => nil
I'm expecting :there, but I get nil.


try something like :

["" [["/about" :about]
       ["/some" :there]]]
I hit the same kind of problems, the easiest way is to play in the repl with bidi examples until it clicks


@malcolmsparks: one other advantage of the 1.1 yada is that Cursive's debugger works properly. With defrecords it's often confused, or just can't bind the breakpoint to any code.


are you still considering the deprecation of maps in bidi route trees and the option to specify yada resources as maps?


@malcolmsparks: is there a reason that the authentication interceptor is before get-properties?


the use case is this: we have a concept of 'apps' in our API. Each app is identified by a path parameter. In order to do the authentication we need the app config. My take on this was assoc'ing the app configuration into the context in the properties interceptor (because it's needed too in the method processing). But that won't work.


The alternative is to add an interceptor. Which might be a good idea anyway, because I don't think it will be possible to generate a 404 when the 'app' doesn't exist as this will be detected in the authentication rather than process-request-body


@nha thank you so much!


@stijn I think it was you that suggested the current scheme. The general default is that authentication can be done on the request only- it is simply a veracity check of the claims made in the request. But authorization may require knowledge of the resource under access. So get-properties is sandwiched in between.


You can always leave the authentication empty and do everything in the authorization interceptor. Or as you say, modify the interceptor chain yourself


ah yes, indeed, the case where you need the resource data before you can do the authorization and were you also need the authentication info to get the resource data


the 'my posts' case


well, I think adding an interceptor is a good idea anyway for our use case. I want to generate a 404 BEFORE even trying to authenticate, because authentication depends on the app config


legacy mobile applications are a pain for an API simple_smile


@malcolmsparks: I also created an issue for the thing we discussed earlier where the 401/403 should be generated


other than that, I think authentication/authorization is structured really well. love the concept of the schemes and there extensibility


It's hard to get something to work in every case. I've decided to base it on the spec rather than common usage. That might be rather opinionated for some. At least interceptors can be reordered


Thanks for the comment :)


How can I 'wrap a session' in yada?

(def api ["/" (yada "hi")])

(start server
        (-> (wrap-session api)
At the moment, this fails with "nth not supported on this type: session$wrap_session$fn_17063." I've tried other combinations like bidi/make-handler first, then wrap-session but still fails. If there's a better way entirely, I'd welcome it. Thank you.