I have been trying to follow https://github.com/plataformatec/devise/wiki/How-To:-Override-confirmations-so-users-can-pick-their-own-passwords-as-part-of-confirmation-activation in order to allow users on my app to supply only an email address when they sign up, and then be prompted for the remainder of their information after they confirm their email. But the approach seems to be slightly broken or I don't fully understand it.
In the instructions, in the confirmations_controller there is this method:
def with_unconfirmed_confirmable
original_token = params[:confirmation_token]
confirmation_token = Devise.token_generator.digest(User, :confirmation_token, original_token)
#confirmable = User.find_or_initialize_with_error_by(:confirmation_token, confirmation_token)
if !#confirmable.new_record?
#confirmable.only_if_unconfirmed {yield}
end
end
If I leave it as is, I always get a "Confirmation Token is Invalid" error. It appears to be due to the new token being generated and not found. You can see what I mean in the log:
Started GET "/users/confirmation?confirmation_token=9835abdff3d03d0a29e1c5a640c6a22f1ed6289b4cf696ed514ba183aad49caa" for 127.0.0.1 at 2013-11-12 07:39:42 -0700
Processing by ConfirmationsController#show as HTML
Parameters: {"confirmation_token"=>"9835abdff3d03d0a29e1c5a640c6a22f1ed6289b4cf696ed514ba183aad49caa"}
ESC[1mESC[36mUser Load (0.3ms)ESC[0m ESC[1mSELECT "users".* FROM "users" WHERE "users"."confirmation_token" = '98e17d2ea3cc3fcba5cab7d37bd9a865fc2e318372cb293b541b8a05b46f
e4a3' LIMIT 1ESC[0m
But if I change the method to use the original_token instead of the generated confirmation_token, it all works. What am I missing? Should I be worried about not using the derived token?
Turns out the error was because my app was on an older version of devise that inadvertently got upgraded to devise 3.1. Thanks to this post: Upgrading to devise 3.1 => getting Reset password token is invalid
I updated the mailer to send the correct token and now all is working.
Related
I have a Ruby On Rails application. Now, I started getting ActionController::InvalidAuthenticityToken error while updating password in admin_controller.
CSRF token is present in layout.
Earlier it was working, today when I get a warning from google to change password, I tried to update the password & got this error.
Below is the request:
Started PATCH "/admin/password/change" for 127.0.0.1 at 2020-07-25 22:05:38 +0530
Processing by Admin::PasswordsController#update as HTML
Parameters: {"utf8"=>"✓", "authenticity_token"=>"osXhNhqJZ9qXeJ4F2BXrJvOTflrG5G3MGPl7yuOa4Y8PoqIXKEVe17bqO5u9nGYG2Bn0Zun2U9mOR4/uxNajsg==", "current_password"=>"[FILTERED]", "password"=>"[FILTERED]", "password_confirmation"=>"[FILTERED]"}
I am using devise-4.3 for authentication.
If tried to update the password 3-4 time, then it works but not each time.
I believe I should refresh the token, turbolinks might be creating an issue.
Every other post/patch request is working.
Ruby-2.4.0, Rails-5.1.4
Go to the controller that’s generating the error, and paste following line of code above all the defined functions:
skip_before_filter :verify_authenticity_token, :only => :create
OR
protect_from_forgery with: :null_session
save it then restart the server!
Let me know if this works for you!
Need to Hard reload the page/disable turbolinks, so I added the following in link_to
<%= link_to 'Change Password', change_admin_password_path, data: { turbolinks: false }) %>
Now the complete page reload is happening and I am able to update the password.
I am working on rails json webservices. I am using warden for authentication in that, its working fine with html format , but in json its not working. because passed parameter is not working in config/intializers/wrden.rb file .below is the code
config/intializers/warden. rb
def authenticate!
Rails.logger.info '!!!!!!!!!!!!!!!!!!!!!!!!!!!!'
Rails.logger.info params['emailID']
user = User.find_by_emailID(params['emailID'])
if user && user.authenticate(params['password'])
success! user
else
fail "Invalid email or password"
end
end
here is log of this
Parameters: {"emailID"=>"xyz#gmail.com", "password"=>"123456", "session"=>{"emailID"=>"xyz#gmail.com", "password"=>"123456"}}
(0.2ms) BEGIN
!!!!!!!!!!!!!!!!!!!!!!!!!!!!
nil
User Load (12.2ms) SELECT "users".* FROM "users" WHERE "users"."emailID" IS **NULL** LIMIT 1
(0.3ms) COMMIT
Completed in 276ms
Well, I just ran into this, too. This GitHub thread fixed it for me:
https://github.com/hassox/warden/issues/84
Basically, tell Warden to use Rails' request object instead of whatever it's using by default. You can use the rails-warden gem or mix this into Warden:
module Warden::Mixins::Common
def request
#request ||= ActionDispatch::Request.new(#env)
end
end
Using Rails 4 and Devise 3.1.0 on my web app. I wrote a Cucumber test to test user sign up; it fails when the "confirm my account" link is clicked from the e-mail.
Scenario: User signs up with valid data # features/users/sign_up.feature:9
When I sign up with valid user data # features/step_definitions/user_steps.rb:87
Then I should receive an email # features/step_definitions/email_steps.rb:51
When I open the email # features/step_definitions/email_steps.rb:76
Then I should see the email delivered from "no-reply#mysite.com" # features/step_definitions/email_steps.rb:116
And I should see "You can confirm your account email through the link below:" in the email body # features/step_definitions/email_steps.rb:108
When I follow "Confirm my account" in the email # features/step_definitions/email_steps.rb:178
Then I should be signed in # features/step_definitions/user_steps.rb:142
expected to find text "Logout" in "...Confirmation token is invalid..." (RSpec::Expectations::ExpectationNotMetError)
./features/step_definitions/user_steps.rb:143:in `/^I should be signed in$
This error is reproducible when I sign up manually through the web server as well, so it doesn't appear to be a Cucumber issue.
I would like:
The user to be able to one-click confirm their account through this e-mail's link
Have the user stay signed in after confirming their account
I have setup:
The latest Devise code, from GitHub (3.1.0, ref 041fcf90807df5efded5fdcd53ced80544e7430f)
A User class that implements confirmable
Using the 'default' confirmation controller (I have not defined my own custom one.)
I have read these posts:
Devise confirmation_token is invalid
Devise 3.1: Now with more secure defaults
GitHub Issue - Devise confirmation_token invalid
And have tried:
Setting config.allow_insecure_tokens_lookup = true in my Devise initializer, which throws an 'unknown method' error on startup. Plus it sounds like this is only supposed to be a temporary fix, so I'd like to avoid using it.
Purged my DB and started from scratch (so no old tokens are present)
Update:
Checking the confirmation token stored on the User after registering. The emails token matches the DBs token. According to the posts above, the new Devise behavior says not supposed to, and that instead it is should generate a second token based on the e-mail's token. This is suspicious. Running User.confirm_by_token('[EMAIL_CONFIRMATION_TOKEN]') returns a User who has errors set "#messages={:confirmation_token=>["is invalid"]}", which appears to be the source of the issue.
Mismatching tokens seems to be the heart of the issue; running the following code in console to manually change the User's confirmation_token causes confirmation to succeed:
new_token = Devise.token_generator.digest(User, :confirmation_token, '[EMAIL_TOKEN]')
u = User.first
u.confirmation_token = new_token
u.save
User.confirm_by_token('[EMAIL_TOKEN]') # Succeeds
So why is it saving the wrong confirmation token to the DB in the first place? I am using a custom registration controller... maybe there's something in it that causes it to be set incorrectly?
routes.rb
devise_for :users,
:path => '',
:path_names => {
:sign_in => 'login',
:sign_out => 'logout',
:sign_up => 'register'
},
:controllers => {
:registrations => "users/registrations",
:sessions => "users/sessions"
}
users/registrations_controller.rb:
class Users::RegistrationsController < Devise::RegistrationsController
def create
# Custom code to fix DateTime issue
Utils::convert_params_date_select params[:user][:profile_attributes], :birthday, nil, true
super
end
def sign_up_params
# TODO: Still need to fix this. Strong parameters with nested attributes not working.
# Permitting all is a security hazard.
params.require(:user).permit!
#params.require(:user).permit(:email, :password, :password_confirmation, :profile_attributes)
end
private :sign_up_params
end
So upgrading to Devise 3.1.0 left some 'cruft' in a view that I hadn't touched in a while.
According to this blog post, you need to change your Devise mailer to use #token instead of the old #resource.confirmation_token.
Find this in app/views/<user>/mailer/confirmation_instructions.html.erb and change it to something like:
<p>Welcome <%= #resource.email %>!</p>
<p>You can confirm your account email through the link below:</p>
<p><%= link_to 'Confirm my account', confirmation_url(#resource, :confirmation_token => #token) %></p>
This should fix any token-based confirmation problems you're having. This is likely to fix any unlock or reset password token problems as well.
A friend of mine just found this question and emailed me asking if I had figured this out, which reminded me that I never submitted my own answer, so here goes :)
I ended up resetting the token & using send to get the raw token. It's ugly, but it works in a punch for devise (3.5.1).
26 it "should auto create org" do
27 email = FG.generate :email
28 visit new_user_registration_path
29 fill_in :user_name, with: 'Ryan Angilly'
30 fill_in :user_user_provided_email, with: email
31 fill_in :user_password, with: '1234567890'
32
33 expect do
34 click_button 'Continue'
35 end.to change { Organization.count }.by(1)
36
37 expect(page.current_path).to eq(confirmation_required_path)
38 u = User.where(email: email).first
39 u.send :generate_confirmation_token
40 email_token = u.instance_variable_get(:#raw_confirmation_token)
41 u.save!
42 os = u.organizations
43 expect(os.size).to eq(1)
44 visit user_confirmation_path(confirmation_token: email_token)
45 o = os.first
46
47 u.reload
48 expect(u.confirmed?)
49 expect(page.current_url).to eq(organization_getting_started_url(o))
50 end
As of devise 3.5.2, the confirmation token is no longer digested during the confirmation process. This means that the token in the email will match the token in the database.
I was still having trouble with confirmations after figuring this out, but in my case it turned out to be a bug I introduced when I overrode find_first_by_auth_conditions. By fixing the bug I introduced in that method, I fixed my errors with confirmation.
I have Omniauth set up with a WePay strategy ( https://github.com/intridea/omniauth ). When getting authorization, it is making the v2/oauth2/token call four times (interspersed with /v2/user calls), but returns on the first access token in the env["omniauth.auth"] variable. This results in both long load times on the callback and a "access_token revoked" error when trying to perform an API call later.
I'm completely flummoxed as to why this is happening. I've tried disabling every method that follows the callback, so I'm pretty sure this is happening within Omniauth itself, as opposed to my app (which is in Rails, btw).
Here's my omniauth.rb initializer file:
require "omniauth/strategies/wepay"
OmniAuth.config.logger = Rails.logger
Rails.application.config.middleware.use OmniAuth::Builder do
provider :wepay, ENV['WEPAY_STAGE_APP_ID'], ENV['WEPAY_STAGE_SECRET']
provider :twitter, ENV['TWITTER_CONSUMER_KEY'], ENV['TWITTER_CONSUMER_SECRET']
provider :facebook, ENV['FACEBOOK_APP_ID'], ENV['FACEBOOK_APP_SECRET']
end
Relevant routes:
match 'auth/wepay/callback', to: 'sessions#wepay'
match 'auth/failure', to: redirect('/organization')
The sessions controller (though I am reasonably confident the loop is happening before this ever gets called):
class SessionsController < ApplicationController
before_filter :get_all_organizations
before_filter :authorize_current_organization
def wepay
current_user.from_omniauth(env["omniauth.auth"])
if #organization.wepay_account_id? == false
#organization.create_wepay_account(current_user)
end
redirect_to transactions_path, notice: 'Login successful.'
end
end
The relevant section of my log:
Started GET "/auth/wepay/" for 127.0.0.1 at 2012-08-26 17:40:18 -0700
(wepay) Request phase initiated.
Started GET "/auth/wepay/callback?code=XXXXX&state=XXXXX" for 127.0.0.1 at 2012-08-26 17:40:25 -0700
(wepay) Callback phase initiated.
Connected to NewRelic Service at collector-6.newrelic.com
Processing by SessionsController#wepay as HTML
Parameters: {"code"=>"XXXXX", "state"=>"XXXXX"}
I'm having a tough time debugging this, but New Relic does show that 548ms are being spent in sessions#wepay, vs 261ms in Net::HTTP[stage.wepayapi.com]: POST. I don't know if that's indicative of anything.
Cool, just checking. On my end, as a test, I just ran the gem through a couple of Rails Omniauth premade apps, both of which were easily able to authenticate and return back to the app. I used these to create the apps:
http://net.tutsplus.com/tutorials/ruby/how-to-use-omniauth-to-authenticate-your-users/
and
http://railsapps.github.com/tutorial-rails-mongoid-omniauth.html
I would check the session controller code, as it may not just be a routing issue.
I have a fairly simple app using devise and cancan for authentication and authorization. Everything works great except when users try signing in with invalid usernames and/or passwords. When this happens, we get an error loading page with the following exception in the logs:
Started POST "/users/sign_in" for 127.0.0.1 at 2012-02-09 22:23:22 -0600
Processing by Devise::SessionsController#create as HTML
Parameters: {"utf8"=>"✓", "authenticity_token"=>"blahblahblahblah", "user"=>{"login"=>"asdasd", "password"=>"[FILTERED]", "remember_me"=>"0"}, "commit"=>"Sign in"}
User Load (0.4ms) SELECT "users".* FROM "users" WHERE (lower(username) = 'asdasd' OR lower(email) = 'asdasd') LIMIT 1
Completed 401 Unauthorized in 74ms
I'm not sure what I need to set to allow the authorization and/or how to get more detailed logs to see exactly what is not authorized? If I enter valid credentials I can access the application and all other pieces of the app work as expected.
I know this question has been posted a couple months ago but I hot the same issue, and after fighting it for a few hours, overwriting Devise SessionController, Devise Custom Failure, debugging through, etc.., I finally found out what was going on and I decided to share the solution so you guys won't have to go through that.
The error 'Completed 401 Unauthorized in XXms' happens within the create method of SessionController at the line:
resource = build_resource(...)
And the resource cannot be built since the resource is not passed to the server. Now the problem resides in WHY the resource isn't passed to the server? I'm using JQUERY mobile which post the sign_in as an AJAX call, which JQUERY cannot upload data like that through AJAX.
You need to add to your signin form the data-ajax=false:
in Devise/sessions/new.html.erb modify the form to look like this:
form_for(resource, :as => resource_name, :url => user_session_url, html: {data: {ajax: false}}) do |f|
Hope that helps someone down the road.