Fork me on GitHub
#yada
<
2016-02-06
>
caleb16:02:47

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)

dominicm17:02:41

@caleb: You mean within a function inside a :METHOD key? (as opposed to a java resource)

dominicm17:02:54

Yada can serve an io/resource directory, so just want to clarify 😛

caleb17:02:20

@dominicm: Yeah, not a java resource, haha.

caleb17:02:05

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

caleb17:02:52

So I need to fetch the account record from the DB after authentication, but before authorization

dominicm17:02:31

Yeah, I believe yada's approach is to do it like you would with ring, and it's along the approach ooff...

dominicm17:02:14

(assoc ctx :response {:status 401}) but @malcolmsparks will probably have to go that deep for you

caleb17:02:13

So would I do the authorization in my :get handler and adjust the status as you mentioned?

caleb17:02:36

Bypassing yada’s own authorization. I think my problem is I don’t have a clear picture of all the “hooks” that yada has

dominicm17:02:07

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)))

dominicm17:02:16

I'm supposed to be reading through the docs today/tomorrow

caleb17:02:03

what is :authorization-key-maybe? Is that in the resource definition?

dominicm17:02:38

I have no idea what the authorization function key is, that was my way of indicating that, should have clarified 😛

caleb18:02:42

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.

caleb18:02:04

If Yada is relatively stable enough, that’s something I could definitely do once I understand it myself

dominicm18:02:22

Yeah, for sure. I think things are just reaching stability, and ergo are just about ready for documenting.

caleb18:02:47

I think the key is :authorization, and the value is a map which has a :methods key

caleb18:02:58

and by default it does role based authorization from what I’ve seen

caleb18:02:10

I think you can specify {:authorization {:algorithm :my-custom-thing}}, and then implement yada.authorization/validate :my-custom-thing to do your own thing

caleb18:02:45

So yeah, I think I’ll have to wait until Malcolm gets in to get a bigger picture.

dominicm18:02:22

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.

caleb18:02:23

Yeah, I see in authorization.clj that it will be renamed :scheme

caleb18:02:39

Which is good because then it will match the authentication system

dominicm18:02:30

ah, interesting.

caleb18:02:54

Okay, I think I have a solution. From interceptors.clj

dominicm18:02:47

ah, good thinking

caleb18:02:56

It looks like :properties is the resource method I want to do the work in. This interceptor list will be helpful

malcolmsparks18:02:45

@caleb you are absolutely right, good detective work!

malcolmsparks18:02:12

The 3 relevant interceptors here are authentication, resource property loading and authorization.

malcolmsparks18:02:49

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.

malcolmsparks18:02:50

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)

malcolmsparks18:02:02

Once the request's claims are verified, and the resource's properties are known, we can validate the access (authorization)

malcolmsparks18:02:29

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.

malcolmsparks18:02:56

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.

malcolmsparks18:02:53

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

malcolmsparks18:02:44

I hope all this info is helpful. I will of course provide full documentation soon.

dominicm19:02:26

@malcolmsparks: I just bumped into the core.cache bug again

dominicm19:02:44

(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"]])

dominicm22:02:50

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

malcolmsparks22:02:38

Sounds like a bug

dominicm23:02:36

I'll go chase it down if I get a chance.