This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-02-06
Channels
- # aatree (1)
- # alda (9)
- # beginners (63)
- # boot (124)
- # braid-chat (8)
- # cider (44)
- # cljs-dev (44)
- # clojure (79)
- # clojure-dev (1)
- # clojure-russia (47)
- # clojurescript (105)
- # community-development (16)
- # cursive (3)
- # datavis (1)
- # datomic (54)
- # editors (10)
- # editors-rus (10)
- # emacs (18)
- # garden (1)
- # hoplon (5)
- # jobs (1)
- # ldnclj (6)
- # lein-figwheel (2)
- # luminus (1)
- # off-topic (29)
- # om (49)
- # overtone (5)
- # parinfer (12)
- # proton (2)
- # re-frame (5)
- # reagent (6)
- # ring-swagger (1)
- # slack-help (3)
- # spacemacs (1)
- # yada (42)
I just discovered Yada so this is a basic question, but if I wanted to “load” my resource from the database in order to do authorization on it, which part of the lifecycle would be best to put it in? (I would then return that resource to the user if they were authorized)
@caleb: You mean within a function inside a :METHOD key? (as opposed to a java resource)
Lets say a user accesses an account resource, and I need to look at the client-id of the logged in user and compare that to the client-id of the account to authorize them
So I need to fetch the account record from the DB after authentication, but before authorization
Yeah, I believe yada's approach is to do it like you would with ring, and it's along the approach ooff...
(assoc ctx :response {:status 401})
but @malcolmsparks will probably have to go that deep for you
So would I do the authorization in my :get
handler and adjust the status as you mentioned?
Bypassing yada’s own authorization. I think my problem is I don’t have a clear picture of all the “hooks” that yada has
or maybe it's using the context in an authorization that's best...
As in
:authorization-key-maybe (fn [ctx] (let [x (get-thing-from-db)] (if? (authzed? x) (assoc ctx :x x) false)))
I have no idea what the authorization function key is, that was my way of indicating that, should have clarified 😛
Oh, okay. Just learning Yada, I have some ideas to help the documentation. One of them is to more clearly give context to all of these keys.
If Yada is relatively stable enough, that’s something I could definitely do once I understand it myself
Yeah, for sure. I think things are just reaching stability, and ergo are just about ready for documenting.
I think you can specify {:authorization {:algorithm :my-custom-thing}}
, and then implement yada.authorization/validate :my-custom-thing
to do your own thing
ah, if there's just that, then I imagine my former idea is probably the closest to correct. I mostly just speculate. I believe that :algorithm key is being renamed to something like :strategy or something less, math sounding.
It looks like :properties
is the resource method I want to do the work in. This interceptor list will be helpful
@caleb you are absolutely right, good detective work!
The 3 relevant interceptors here are authentication, resource property loading and authorization.
Authentication is in the process of being documented. Authentication is only concerned with the veracity of the request's claims, so is independent of the resource and can therefore be executed first.
Then the resource's properties are loaded, which could involve a trip to the database (remember it's ok to return a future or promise here is you like)
Once the request's claims are verified, and the resource's properties are known, we can validate the access (authorization)
This is the most open ended because authorization usually involves domain logic. The default algorithm is a primitive boolean RBAC affair, ok for maybe 50% of usages, where the authorization is independent of a resources properties.
But if authorization depends on a resource's properties, (e.g. Ensure Alice can access her bank account but not Bob's) you'll need to specify your own defmethod and declare the algorithm key in the resource model.
The only thing left to say is that I'm unhappy with the term 'algorithm'. I considered scheme but risks confusion with authentication scheme. So I'm open to suggestions as to a better word. Therefore, please go ahead and use :algorithm but be prepared to update your code on a future yada release
I hope all this info is helpful. I will of course provide full documentation soon.
@malcolmsparks: I just bumped into the core.cache bug again
(def server-deps '[[aleph "0.4.1-beta2"]
[byte-streams "0.2.0"]
[manifold "0.1.2"]
[yada "1.1.0-20160204.230009-18"]
[com.stuartsierra/component "0.3.1"]
[reloaded.repl "0.2.1"]])
@malcolmsparks: it seems that when a list is returned as a body, they are (apply str body)
instead of encoded. e.g. a list of '("_replicator" "_users")
becomes _replicator_users
in the output. Is there a reason for this? Or is it a mistake? When passed to cheshire, it becomes a vector.
Sounds like a bug