passing optional params to authorize_resource

[slashmili]

I explained why I need it here: jarednorman/canada#11

Do you have any suggestion or alternative way of doing that?

[cpjk]

If Canada will not support an options argument, then I think the only way from Canary's perspective would be to take options from the plug opts and wrap them up into the resource struct that we pass as the third argument to Canada.can? after we fetch that resource from the db.

Then the user could rely on these options within the Canada.can? implementation. However, this is really just a hack to get around Canada's 3 argument limit, and I don't like it.

One option is for Canary to stop relying on Canada, but copy the implementation, allowing for an options argument.

I'm open to suggestions.

[slashmili]

I thought about few ideas like this but as you said it would be hack. I am all for having our own permission definitions module.

I understand that this change breaks the backward compatibility, so I suggest that make it a configuration to what module use.

Of course we can also convince @jarednorman that this is something that is needed and implement it in canada 😬

[jarednorman]

If you want to whip up a proof of concept for Canada, I'll take a look, but no guarantees. I'm currently quite happy with its simplicity and don't want to add anything unless I'm sure it's worth it.

[nmcalabroso]

+1 to this.

My use case is that my lib/abilities.ex needs to be able to support an optional parameter to be able to decide on the authorization definition. Specifically, I need to be able to pass the query string parameters to a non-id action. Here's the example:

defimpl Canada.Can, for: SampleProject.Account.User do
  def can?(current_user, :index_by_user, Applicant) do
    # user_id should come from the query parameters but right now there's no way to do this
    is_team_lead_of_user(current_user.id, user_id)
  end
end

[ghatighorias]

I think authorize_controller should fix your problem. It is committed but the new version of canary is not out.

So what it does is that instead of model it tells can? function which user is requesting which controller with what action.

[slashmili]

@ghatighorias it's still an improvement but doesn't solve my case :(

I want to give access to members of a group to Page A but not Page B.

So the variables of making this decision are:

• User
• Group
• ControllerA or ControllerB

authorize_controller is adding ControllerA by removing Group

I wish you had implemented it to call can? with these arguments:

User.Can?(user, [ControllerA, :show], group)

[slashmili]

@ghatighorias just noticed that it was already there!

@cpjk what do you think about this approach ?

[ghatighorias]

@slashmili I don't see it is to be of a huge improvement.
if you use authorize_controller ControllerA.
then you will know which user, called which action from which controller.
this should be enough information for you to write a custom function that gives you back the group name

PS: authorize_controller uses ":canary_controller" . you can populate that with a tupe {group, controller} and then have it in the can? function

[slashmili]

@ghatighorias

then you will know which user, called which action from which controller.

Not really they user is loaded from Session. So any user might visit a route with ControllerA and try to access the resource.

PS: authorize_controller uses ":canary_controller" . you can populate that with a tupe {group, controller} and then have it in the can? function

That's a good idea! I'll give it a try.