Reputation: 1356
I'm having an issue with the devise reset password link (Rails 4). It is correctly sent, but when the user clicks the link, they are redirected to the homepage.
This only happens in production. It works perfect in development.
When the link it sent, it is in correct form, e.g:
http://website.com/d/users/password/edit?reset_password_token=gmf7ssHx4QRmUBdGb1nr
Running rake routes, everything tells me it should be pointing to the PasswordsController
in devise:
new_user_password GET /d/users/password/new(.:format) passwords#new
edit_user_password GET /d/users/password/edit(.:format) passwords#edit
PATCH /d/users/password(.:format) passwords#update
PUT /d/users/password(.:format) passwords#update
I figure it must be some redirect happening in the PasswordsController
of devise. There are only two places in the edit method a redirect would happen, require_no_authentication
and assert_reset_token_passed
. So I overwrite the edit methods with some puts and check the logs.
class PasswordsController < Devise::PasswordsController
def require_no_authentication
assert_is_devise_resource!
return unless is_navigational_format?
no_input = devise_mapping.no_input_strategies
authenticated = if no_input.present?
args = no_input.dup.push scope: resource_name
warden.authenticate?(*args)
else
warden.authenticated?(resource_name)
end
if authenticated && resource = warden.user(resource_name)
flash[:alert] = I18n.t("devise.failure.already_authenticated")
puts "=========================="
puts "APPARENTLY IM ALREADY AUTHENTICATED WTF?"
puts "=========================="
redirect_to after_sign_in_path_for(resource)
end
end
protected
# Check if a reset_password_token is provided in the request
def assert_reset_token_passed
if params[:reset_password_token].blank?
puts "reset_password_token is blank!!!"
set_flash_message(:alert, :no_token)
redirect_to new_session_path(resource_name)
else
puts "reset password token NOT blank"
end
end
end
Results in development: both put statements show up as expected.
Results in production: NO puts statements show up anywhere. In fact, when I check the live logs and go to the reset password link, it shows that it is directly going to the homepage:
2016-08-05T23:00:15.166276+00:00 app[web.1]: Started GET "/" for 177.227.42.66 at 2016-08-05 23:00:15 +0000
2016-08-05T23:00:15.168243+00:00 app[web.1]: Processing by PageController#index as HTML
I'm stumped on this one. How do the logs not show EITHER of those methods being called? I confirmed the deployment worked correctly and restarted heroku server.
Thanks!
Upvotes: 2
Views: 531
Reputation: 2916
You have a redirect happening before the request reaches your server that is dropping the path. For example, example.com/aboutus gets redirected to www.example.com without the '/aboutus'.
(Converted my comment above to an answer)
Upvotes: 1