I want users to interact with my site without having to create an account and then later create an account (supply password, name info..etc) if they want more.
This works fine but if user thought they've created an account and then tried to login (likely using a password they use all the time) Devise will through an Exception:
BCrypt::Errors::InvalidHash in Devise/sessionsController#create
Because password is nil. If they go through the signup and then signin again, it works.
I'm using devise (1.2.0), Rails (3.0.4) and Ruby 1.9.2
I mean I can go around it by creating a dummy password and have a field to say if the user has signed up (or check if other mandatory fields have been provided) then resetting the password on actual sign up but I think in all cases it shouldn't through the above exception.
Is there anything I can do/set to go around the problem?
The easiest way is probably to just generate a random one, using something like Devise.friendly_token[0..20] but you could also override the Devise controller and method for logging in, rescue the exception, and just redirect.
Related
Stack:
Devise 3.1.1
Rails 4.0.5
Omniauth 1.2.2
I started running into this issue where users can reset their passwords (via email), but the changed password never gets saved. Basically the only way they can login is through password reset.
I'm not necessarily looking for a solution, but can anyone recommend how to DEBUG what is going on? Ideally I'd like to follow the password reset path within Devise so I can verify the new password is getting saved, but I don't know where to start looking or where to put "puts" statements.
Also, it only happens on SOME accounts, which is even weirder.
Turns out a bug on my part. I was improperly overriding find_first_by_auth_conditions
Im trying to customize Devise registration process to generate a random password and sends it with the confirmation mail.
What I have already done is to override the default Devise's :validtable and to generate a new random password if needed.
before_validation :password_generation
def password_generation
password_confirmation = password = Devise.friendly_token.first(7) if password.nil? || password.blank?
end
Now my problem is to include the newly generated random password with the original confirmation mail.
Is there any possibility to keep up with the original usability of Devise while customizing it's new user process or should I build the authentication process from scratch ?
Thanks,
Hadar.
(four months too late, but perhaps someone else can use this)
Mostly what you need to do is copy the default Devise mailer and views to your project and in the config/initializers/devise.rb specify your local class in config.mailer. At that point, you can customize the email as you like. (note that Devise uses the term resource as an abstraction, but mostly it means an instance of User).
The only trick will be to find a way to remember the generated password between the time that the new user account is created and when the email is generated and sent. What Devise will store, when saving the user record is an encrypted version of the password. I would have to follow the path of logic in Devise to be sure, but I'll bet you could store it in an instance variable on User, perhaps params or maybe the flash. Be very careful about this; you want this value to be as short-lived as possible -- presumably just the lifetime of the request.
I'm using Devise with multiple scopes (in this case, a user scope and an admin scope) and admins are able to 'become' a user using the approach on the Devise wiki. This works well, except that I have one particular page that requires the use of an auth token that causes a problem with a session logged in under both a user and admin scope. The page generates a POST to a controller that requires a user to be logged in using the user auth token. The POST succeeds, but afterwards, the admin scope has been signed out. (Meaning that admin_signed_in? returns false.) Other pages that execute POSTs to the same controller without requiring the auth token work as expected without logging out the admin scope.
I suspect that something is going on with token_authenticatable where the authentication of any scopes other than the one associated with that specific token are logged out. I've searched for references in the devise gem source to both the devise sign_out and warden logout methods that could be invoked as part of the token_authenticatable functionality and wasn't able to find anything.
This is happening with Devise 1.3.4. Any help is appreciated.
In case anyone else is looking for a solution to this, I found that the before_filter/after_filter approach I described in the comment to my question seems to work fine. I think that a better, more general solution to this would be to make a change to the devise gem and underlying calls to warden, but didn't have time to make those changes for this particular problem yet.
I already migrating from restful_authentification to devise.
I follow every steps. I succeed sign up new user, confirm it.
also login with it's user. Everything is going right.
Until I found a bugs. That some of current user who already able to login with restful_authentification,
cannot login. It returns "Invalid username and password".
It is possible the reason is coursed from different password encryption system between restful_authentification and devise?
Or Devise didn't allow some characters on password?
Please help me? Its already 2 days find ways to resolve the issue
Thanks
Did you configure Devise to use the :restful_authentication_sha1 encryptor, the correct pepper and stretches? See https://github.com/plataformatec/devise/wiki/How-To:-Migrate-from-restful_authentication-to-Devise
I do not know restful_authentication, but i think you will have to reset the passwords of all the users that existed before. It is safe to assume that devise uses a different algorithm to encode the password.
When resetting the password from the console, you need to specify the :password and the :password_confirmation, otherwise it will not work.
I'm using Devise in a Rails 3 app, and I successfully configured it so that it uses a username as its authentication method instead of an email. The problem is that in the default registrations controller for devise, it calls an "update_with_password" method on the params passed in, which effectively allows users to change their username, and password. This behaviour makes sense if you're using email as an authentication method, since it's reasonable to expect people to be able to change their email. However, with using usernames, I'd rather users not be able to change them; I only want them to be able to change their password. Would this best way to do this be to override the RegistrationsController, and prevent the mass-assignment of params so that only the password can be changed?
Hope this is clear. Thanks!
Ok, I solved it. I added attr_readonly to the username variable, so that it cannot be changed with mass assignment.