Controlling re-direct after submitting a password reset request?

1,366 views
Skip to first unread message

David Christiansen

unread,
Jan 3, 2011, 9:12:35 AM1/3/11
to plataforma...@googlegroups.com
How do I tell devise where to re-direct to after requesting a password reset?

--
David Christiansen
Founder and Owner, TroopTrack LLC

da...@trooptrack.com
www.trooptrack.com
Boy Scout Troop Management for the 21st Century
317-966-6154 (mobile)

Carlos Antonio da Silva

unread,
Jan 3, 2011, 10:06:05 AM1/3/11
to plataforma...@googlegroups.com
As you can see, the redirect is done inside passwords_controller and it is not configurable.
You'd have to inherit from Devise controller and override the create action to redirect to where you want, take a look at the wiki, there is info about how to inherit Devise controllers there.
--
At.
Carlos A. da Silva

Carlos Antonio da Silva

unread,
Jan 3, 2011, 10:07:27 AM1/3/11
to plataforma...@googlegroups.com

Kyle Shipley

unread,
Jan 3, 2011, 11:05:49 AM1/3/11
to plataforma...@googlegroups.com
(Note: I work with Dave, and I want to clarify the original question a bit.)

Because of some other application needs, we're not using a User model for devise, but rather an Author model.  When I submit the password reset, an email is generated, but the path it tries to redirect to is /session/new.author, instead of the expected /authors/sign_in.  I could subclass the PasswordsController, but this feels like a bug in the devise routing, Rails path generation, or our configuration, and shouldn't require subclassing.

Just for the record, I subclassed the SessionsController to point to Authors::SessionsController in our app, using devise_for.  Could this be part of the issue?

Thoughts?

kshipley

unread,
Jan 3, 2011, 11:21:21 AM1/3/11
to plataforma...@googlegroups.com
Some further clarification -- it looks like new_session_path(resource_name) is broken throughout the application, and not just in this controller.  Do we need to subclass and override every view that uses it, or is there a simple configuration option or route definition that I've failed to set?

Carlos Antonio da Silva

unread,
Jan 3, 2011, 12:33:12 PM1/3/11
to plataforma...@googlegroups.com
So now it sounds more like a Devise issue. new_session_path(:author) should be the same as new_author_session_path basically. What is the output of rake routes for this route? What comes from the console when you call app.new_author_session_path? And what's your resource_name at that point?


On Mon, Jan 3, 2011 at 2:21 PM, kshipley <ship...@gmail.com> wrote:
Some further clarification -- it looks like new_session_path(resource_name) is broken throughout the application, and not just in this controller.  Do we need to subclass and override every view that uses it, or is there a simple configuration option or route definition that I've failed to set?



kshipley

unread,
Jan 3, 2011, 2:09:44 PM1/3/11
to plataforma...@googlegroups.com
The relevant line in rake routes is:
new_author_session GET    /authors/sign_in(.:format)                                   {:action=>"new", :controller=>"authors/sessions"}
This appears to be the highest priority route that could possibly match, although it is not the first route in the file.

app.new_author_session_path returns /authors/sign_in in the console.

When I put a raise in the Devise::PasswordsController, the resource_name is :author as expected.

Carlos Antonio da Silva

unread,
Jan 3, 2011, 5:00:58 PM1/3/11
to plataforma...@googlegroups.com
It seems everything is fine, how's your devise_for call in routes?
Are you able to reproduce it in another small app?

kshipley

unread,
Jan 17, 2011, 6:06:43 PM1/17/11
to plataforma...@googlegroups.com
After some further examination, it looks like this is likely a clash between Devise and Authlogic.  We're using Refinery CMS for this project, and they are in the process of porting to Devise, but aren't there yet.  My guess is that Refinery and/or Authlogic is hijacking the new_session_path route and incorrectly (for our purposes) creating /session/new.author instead of /author/sign_in.

I'm not sure if there's a good way to resolve this sort of conflict other than overriding the controllers and views to use the more explicit new_author_sessions_path form of the route.  If you know of one, though, we're open to it!  Otherwise, I think we have a workaround for now.

Thanks!
Reply all
Reply to author
Forward
0 new messages