0

After the user confirms his account, when he clicks in the link sent to his email, he automatically signs in. How can I disable this characteristic? is it possible?

Flezcano
  • 1,647
  • 5
  • 22
  • 39
  • 1
    Which version of devise are you using? In 3.1 and later, the default is for the user *not* to be logged in, unless you have `config.allow_insecure_sign_in_after_confirmation = true` in your `config/initializers/devise.rb`. – Tim Jun 16 '14 at 21:54
  • well, yes you were right, just updated from 2.2.4 to 3.2.4. I restarted the server, but the user still logs in the project automatically. Is there anything else should I do? – Flezcano Jul 11 '14 at 17:37
  • 1
    If you definitely haven't got `config.allow_insecure_sign_in_after_confirmation = true` in your `config/initializers/devise.rb`, then it would be useful to know the relevant devise routes in you project and whether you've customised/overridden any of devise's controllers/views. – Tim Jul 15 '14 at 21:02
  • Glad it works. Your issue with tokens may be related (see the part of my answer about digested tokens if it was a token that existed before your devise upgrade) or it may be unrelated, in which case this question I answered a while ago might be of use if you are using an `after_create` callback: http://stackoverflow.com/questions/21567625/devise-confirmation-invalid-on-first-send/21917636 -- otherwise it would be best to raise a new question with more details on your problem, info from log etc. – Tim Jul 16 '14 at 09:59

1 Answers1

1

This was the default behaviour in versions of devise before 3.1 and as far as I know there is no trivial way to change it. I think you would need to override devise's ConfirmationsController.

The behaviour changed in 3.1, so that the default is that the user is not logged in after using the confirmation link. If you wanted to retain the old behaviour of logging in, you would need to have config.allow_insecure_sign_in_after_confirmation = true in your config/initializers/devise.rb.

As discussed in the comments, upgrading from devise 2.2.4 to 3.2.4 resulted in the behaviour changing to be what you wanted.

Devise 3.1 introduced a number of other security-related changes. More information is available here: http://blog.plataformatec.com.br/2013/08/devise-3-1-now-with-more-secure-defaults/

Note that one of the other changes in 3.1 was that confirmation/reset/unlock tokens are stored digested in the database, so previously-stored tokens won't work unless you set config.allow_insecure_token_lookup = true in your config/initializers/devise.rb, ideally temporarily so users who just requested a token can use it but after removal of this line all future lookups will assume digested tokens are in the db. See the above link for more detail.

Tim
  • 2,903
  • 2
  • 18
  • 16