Spent some time working with Art, and we've discovered a bug with the password format update. I will work on a fix, but in the meantime I though I would describe it.
Basically, when a user logs in for the first time with an "old style" password (stored in the users table), the new entry in users_secure gets created based on the text for the username the user entered instead of the data in the username column of the old, and there are subsequent problems logging in due to mismatching case.
To reproduce in a clean environment I did the following.
1. Create new user username='testcase'
2. Delete entry in users_secure for newly created user
3. Update password column for 'testcase' row in users table with an old style SHA1 password
4. Log in to OpenEMR using Testcase (capitalize the username)
5. A redirect will happen back to the login page indicating "security changes"
6. At this point it's not possible to login with either "Testcase" or "testcase" as a user name
Inspecting the users_secure table will show the username as "Testcase" while in users it's still "testcase", this mismatch in case is causing problems.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The great thing about this bug is that once the transformation is complete, the problem goes away forever. Unfortunately, one of the first (the first?) sizable clinics to install dev4.1.2 ran into it, invalidating the supposition that it isn't that big of a deal. I just wish no-one had ever discovered the oversight. Leave it to me to trip over every available rock. Bugs Bunny to Daffy Duck: "Nyaaaa...Hey Doc? Whadda ya mean you don't know where the land mines are? You hit every one!" (Munch munch munch).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A sql statement to "batch update" mismatched case between users and users_secure wouldn't be too hard to whip up if you run into a lot more problems with this. Let me know if you think it would be useful.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Looks like we are close to resolution over here. I am not totally sure we are in the clear; Actually I am not sure where we are with anything right now. Too strung out. Are we in the clear for this as released with RC4.1.2, or is a proviso required?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Spent some time working with Art, and we've discovered a bug with the password format update. I will work on a fix, but in the meantime I though I would describe it.
Basically, when a user logs in for the first time with an "old style" password (stored in the users table), the new entry in users_secure gets created based on the text for the username the user entered instead of the data in the username column of the old, and there are subsequent problems logging in due to mismatching case.
To reproduce in a clean environment I did the following.
1. Create new user username='testcase'
2. Delete entry in users_secure for newly created user
3. Update password column for 'testcase' row in users table with an old style SHA1 password
4. Log in to OpenEMR using Testcase (capitalize the username)
5. A redirect will happen back to the login page indicating "security changes"
6. At this point it's not possible to login with either "Testcase" or "testcase" as a user name
Inspecting the users_secure table will show the username as "Testcase" while in users it's still "testcase", this mismatch in case is causing problems.
The great thing about this bug is that once the transformation is complete, the problem goes away forever. Unfortunately, one of the first (the first?) sizable clinics to install dev4.1.2 ran into it, invalidating the supposition that it isn't that big of a deal. I just wish no-one had ever discovered the oversight. Leave it to me to trip over every available rock. Bugs Bunny to Daffy Duck: "Nyaaaa...Hey Doc? Whadda ya mean you don't know where the land mines are? You hit every one!" (Munch munch munch).
A sql statement to "batch update" mismatched case between users and users_secure wouldn't be too hard to whip up if you run into a lot more problems with this. Let me know if you think it would be useful.
Looks like we are close to resolution over here. I am not totally sure we are in the clear; Actually I am not sure where we are with anything right now. Too strung out. Are we in the clear for this as released with RC4.1.2, or is a proviso required?
https://github.com/yehster/openemr/commit/63ff3527ae33b83c76158459e43fa8482cd6914d
I pushed this commit to make usernames case sensitive.
Art, you probably want to get this fix onto your system so that if people logon with caps lock it won't screw up their credentials as we had happen before.