You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Could devise_invitable now consider changing accordingly?
The reason they rationalized being able to do it is because they no longer log users in after confirming (in case the system uses 2-factor). I think maybe devise invitable doesn't have to worry about that, since the user is always brand new?
The text was updated successfully, but these errors were encountered:
I have been thinking in this and not sure if it's safe. If raw token is stored, getting access to DB can allow to get access to an account, it would be a new account, but an accounting binded to an email, so it's similar to reasons to store encrypted token for remember password. In a social media web, for example, attacker could contact with inviter, and inviter would think it's talking with a friend, so attacker would be forging identity.
Maybe a config option could be added, default to encrypted which is safest.
In Feb 2014 I brought up the idea of plaintext tokens: #444
As of devise 3.5.2, devise no longer uses them for email confirmation (oddly categorized as a bug fix)
Could devise_invitable now consider changing accordingly?
The reason they rationalized being able to do it is because they no longer log users in after confirming (in case the system uses 2-factor). I think maybe devise invitable doesn't have to worry about that, since the user is always brand new?
The text was updated successfully, but these errors were encountered: