Add view helpers
schrockwell opened this issue · 14 comments
Something more terse than Authy.authorized?(@conn.assigns.current_user, :action, resource)
With some imports and helper functions that live outside our bailiwick, that turns into authorized?(current_user(conn), :action, resource)
. We could theoretically shorten that to (conn, :action, resource)
, but that seems like a lot less clarity for no real benefit.
I don't know that we need explicit view helpers, but we might want to provide a section in the Readme about view usage.
Hello there!
I suppose that for some cases we can use view helper like
can?(conn, :action)
We can skip passing resource, when we are currently at Posts#index action
, and we want to use the same resource name for Posts#new
.
In such situation we can detect resource name from conn
variable.
@Mehonoshin I like the thought, but it assumes too much about what you're trying to authorize and thus only works in the most basic CRUD cases. For example if you have an index action that lists a bunch of resources, you might need to authorize an "edit" action for each individual resource. Or maybe you're authorizing a nested resource or another resource entirely (e.g. something in the page layout unrelated to the current request).
The only way to cover these cases is to provide all three authorization parameters: the user (implicitly, through the conn
), the action, and the resource (or module).
@schrockwell ok, I accept your position.
Anyway, I'll make a PR with simple can?
view helper with 3 params. I think it is required quite often.
Or its better to add instruction to readme, that we can import controller helpers to view modules?
Thoughts?
For me can?(@conn.assigns.user, :action, resource)
would be just fine. @conn.assigns.user
can be written as @user
:
The way we pass data into a template is by the assigns map, and the way we get the values out of the assigns map is by referencing the keys with a preceding @. @ is actually a macro that translates @key to Map.get(assigns, :key).
So we'd end up with can?(@user, :action, resource)
, which is short and simple, yet powerful👍
Ok, I'll make PR with three-arguments helper tomorrow!
@Mehonoshin Great, thanks! You might think about accepting a %Plug.Conn{}
as the first argument as well, as bodyguard already assumes the user to be assigned to current_user
. We could then just pass the @conn
, which is nicer than @current_user
as the first argument, but still pass other users as first argument when needed.
I've submitted a PR, please check it
@Mehonoshin Looking good, already using it 👍 @schrockwell can you merge this?
Just in case someone else wants to try it as well:
{:bodyguard, github: "Mehonoshin/bodyguard", branch: "view_helpers"}
This is a great idea, thanks guys. I'm going to accept the PR but tweak the implementation a bit. I'd like to call Bodyguard.authorized?
directly and drop Bodyguard.Controller.authorized?
, because it doesn't fit with the rest of the functions in that module, which return a modified conn
with the bodyguard_authorized
flag set.
Here's the tweaked version – any issue with this? 36924ef
@schrockwell Just tried it, no problems for me
Released in v0.5.0.