Was surprised this wasn't the default behavior.
Especially an issue as I just migrated 700 users to MyBB from MegaBBS.
The only way to make the different encryptions to work is to get everyone to update their password, but without them being forced to the update password link, it's going to cause a lot of future problems.
But with the password feature forcing an email, then not requiring a NEW password after the random one is set, it should cause some problems I would think
I don't follow. If you redirect them to the update password link, how are they supposed to navigate to other pages on the board? We obviously can't tell if their account has already been updated or not, so we can't track them in that way. And what about other guests who don't have an account? How are they going to not be stuck with the update password page?
The password feature is that way for security reasons.
Tikitiki Wrote:I don't follow. If you redirect them to the update password link, how are they supposed to navigate to other pages on the board? We obviously can't tell if their account has already been updated or not, so we can't track them in that way. And what about other guests who don't have an account? How are they going to not be stuck with the update password page?
The password feature is that way for security reasons.
Couldn't you use a "refferer" code or something?
I mean...I see your point how it would be difficult...hrmmm...
Wait how about this, I have an idea. What if in the users database was a key for "temp_password".
If they request a temp password, and that gets set to 1, then you could have the login script do a quick check. If temp_password = 1, then the login screen doesn't take them to the forum, but rather to the password reset page!
Thoughts? Comments? I'm not a PHP programmer, so I don't know how realistic this is to do, just thinking out loud.
If temp_password = 1
Yeh, but how can you tell which user is it at the login screen? Track them by IP? That would be doable, but IP's change so it's not realistic.
Tikitiki Wrote:Yeh, but how can you tell which user is it at the login screen? Track them by IP? That would be doable, but IP's change so it's not realistic.
Wouldn't you have that information when they hit "submit" after entering their
userid and
password ?
So after submit, the general logic would be:
if password match = true and temp_password = false then
Forward to Forums homepage
elseif password match = true and temp_password = true then
Forward to Password Reset
endif
I thought there would be no password because of the encryption?
Tikitiki Wrote:I thought there would be no password because of the encryption?
I don't know how the encryption stuff would work. I know passwords are stored in the DB, you just don't recognize them...
so instead of something like:
yx2Kzvw as a randomly generated password you see:
E565B27CC676B4EDF8782BC607F4D668700A3DE1
That's why I think you'd need an additional field to have an indication of if it was a temporary password or not.
I'm with CinciBearFan on this one. With a temp_password flag (not key!) in the users table, this should be very doable.
Upon login, see if the temp_password flag is set; if so redirect them to the change password screen. If not, continue with the current behavior (sent back where they came from).
When a password is set by the user, instead of just updating the password field, set temp_password to false. When admin changes a user's password, there should be a "require password reset" button.