I like method B as well. Maybe name it __create_user__ to match Elixir’s convention for “magic” identifiers.
schrockwell
0
jeffdeville
You got it.
jeffdeville
If anyone with more macro-writing experience wouldn’t mind critiquing what I have, here it is:
https://github.com/schrockwell/bodyguard/pull/31/files
There’s plenty of cleanup to do and docs to write, but the macro itself is the part I’m least confident of. Specifically, why did I have to var!(user) on line 80?
0
OvermindDL1
Is this for per-function testing before the body is called? I often have to check permissions inside the body, not knowing what I can check for until I get the query/queries/remote_response/etc back.
0
jeffdeville
Wow. Well with a use case like that, Bodyguard wouldn’t be a great match for your app even before introducing this macro, I guess.
0
OvermindDL1
This is pretty common here due to interactions with an utterly ancient database with incredibly fine-grained permissions. ^.^;
It is a pretty cool setup though that I have to deal with, should be a use-case that bodyguard should support. 
0
jeremyjh
I think it is pretty common to have multiple layers of security. You’ve got high-level perimeter security - is this a known person and can he even access these resource types - and then you may have business logic that governs what you can do with an individual record. For example in an HR system - you are a manager so you can access the compensation page - but which employees can you see? Just the employees who report up to you.
Putting perimeter security in the controller - where we deserialize and sanitize all the untrusted input coming from the world - doesn’t sound like the wrong thing to me.
0
OvermindDL1
What about when you need to do the same security on a websocket connection? Or a TCP connection? Or something else? You start duplicating code. Better to put all work into a context (as phoenix calls it) including the authentication, then just call those.
0
cleaver
An interesting article about authorization: https://betterment.engineering/whats-the-best-authorization-framework-none-at-all-92e6711ee41b
They make some very good points about keeping it simple—even to the point where they don’t use frameworks at all. Particularly, I like:
- Don’t create an endpoint that you don’t need. Eg. if you want to be sure the user can only see their own account, don’t create a GET /accounts/:id endpoint.
- Build a separate app for different audiences. Eg. public facing app and a separate customer service app.
0
jeffdeville
Wow. Well, I can’t say that it’s the wrong call given the importance of security to their business, but for most shops, not using an auth framework, and instead writing completely new apps for each ‘role’ doesn’t strike me as a great balance of cost/benefit.
0