This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-03-23
Channels
- # admin-announcements (6)
- # aleph (3)
- # beginners (38)
- # boot (119)
- # braid-chat (15)
- # braveandtrue (1)
- # clara (4)
- # cljs-dev (56)
- # cljsfiddle (12)
- # cljsjs (15)
- # cljsrn (6)
- # clojars (4)
- # clojure (113)
- # clojure-art (1)
- # clojure-berlin (1)
- # clojure-dusseldorf (3)
- # clojure-india (15)
- # clojure-new-zealand (3)
- # clojure-poland (1)
- # clojure-russia (83)
- # clojure-uk (18)
- # clojurescript (97)
- # community-development (9)
- # cursive (1)
- # data-science (1)
- # datomic (12)
- # emacs (14)
- # hoplon (350)
- # immutant (2)
- # jobs (2)
- # jobs-discuss (23)
- # keechma (74)
- # liberator (1)
- # off-topic (1)
- # om (127)
- # onyx (54)
- # parinfer (74)
- # pedestal (1)
- # proton (5)
- # re-frame (6)
- # reagent (4)
- # remote-jobs (17)
- # ring-swagger (1)
- # slack-help (5)
- # untangled (16)
- # yada (21)
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
@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
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
@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)
(bidi/make-handler)))
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.