Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pundit + Gems like Devise, "right" way to handle it? #113

Closed
guareschi opened this issue Feb 25, 2014 · 10 comments
Closed

Pundit + Gems like Devise, "right" way to handle it? #113

guareschi opened this issue Feb 25, 2014 · 10 comments

Comments

@guareschi
Copy link

What is the "right" way to handle models/controller policies when these classes come from a gem, like, say, Devise?

Having a solid example for a public auth gem like Devise would make for a great learning experience for those who are a bit more green in ruby and rails.

@tbuehlmann
Copy link

Not sure I understand the question. Devise is authentication only, so your only thing to do should be to define #pundit_user in your controller and define policies.

@guareschi
Copy link
Author

When I followed the README examples, i.e. adding

after_action :verify_authorized, except: :index

to application_controller.rb, I get errors from the devise controllers unless I import all of them and authorise them. I do have a user policy but that doesn't seem to be enough for all the features in devise (sessions, confirm password functionality, forgot password functionality).

I momentarily resolved this problem by removing that line from the application controller and just added it to the controllers for app specific stuff that I control.

Alternatively I authorised the controllers themselves by importing them and doing authorise self in the methods.

I hope this clarifies even just a little the current scenario.

@jnicklas
Copy link
Collaborator

verify_authorized is just a safety net for you as the developer. It doesn't really do anything.

@guareschi
Copy link
Author

But once I removed it all the double render errors and the not authorised errors that were triggered in devise context (login, forgot password etc.) went away

@jnicklas
Copy link
Collaborator

@guareschi it's not a problem to remove it. You can also add a conditional to the before filter to exclude Devise's controller, IIRC before_action takes an if param, but I can't find it's documentation. (wtf?) Another way is to simply do something like:

def verify_authorized
  super unless inside_devise?
end

Where inside_devise? somehow checks if you're inside a Devise controller. Haven't used Devise in years so I have no idea how you'd do that.

@thomasklemm
Copy link
Collaborator

@guareschi Does each of your controller actions really need to be authorized? If not, just put this this in the controllers that carry authorization logic, and avoid the ApplicationController that all controllers inherit from.

@fangari
Copy link

fangari commented Feb 28, 2014

@guareschi if you want to skip the verification when on the Devise controller you should try:

before_action :verify_authorized, except: index, unless: :devise_controller?

Worked for me

@fercreek
Copy link

fercreek commented Nov 1, 2017

To me works with after_action :verify_authorized, except: :index

@jasonswett
Copy link

@fangari Is the except: index going to apply to most people reading this or is that specific to your situation? I'm concerned that people may copy and paste your line wholesale without realizing that except: index is (AFAICT) not a necessary part of the solution and pokes a hole in the intended safety net. Let me know if I'm misunderstanding something.

The version I used was:

after_action :verify_authorized, unless: :devise_controller?

@asecondwill
Copy link

now needs to be as follows I think:

after_action :verify_authorized, except: :index, unless: -> { devise_controller? }

solebared added a commit to rubyforgood/mutual-aid that referenced this issue Jan 18, 2021
solebared added a commit to rubyforgood/mutual-aid that referenced this issue Jan 18, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants