Created attachment 5344 [details] [review] Correct a double password encryption problem in import_borrowers.pl In import_borrowers.pl, if no default password is specified and there is no password column in the imported CSV file, the borrowers that are modified get their password encrypted a second time. What happens : If we try to modify an existing user, the password from the BD is fetched and sent to ModMember, which then encrypts the already-encrypted password a second time. Patch attached to correct the problems. Patch created on Koha version 3.2.3
I want to confirm that this is the same problem I'm seeing in multiple places (including current head). If I import a patron .csv file with a limited number of fields, like cardnumber,surname,branchcode,categorycode,dateexpiry where the goal is to update a specific field (like expiration date), it is screwing up the password even though the password field is not included in the .csv. Does that sound like the same problem?
(In reply to comment #1) > I want to confirm that this is the same problem I'm seeing in multiple places > (including current head). If I import a patron .csv file with a limited number > of fields, like > > cardnumber,surname,branchcode,categorycode,dateexpiry > > where the goal is to update a specific field (like expiration date), it is > screwing up the password even though the password field is not included in the > .csv. > > Does that sound like the same problem? I confirm, it is the same problem. The already encrypted passwords get encrypted a second time, which makes them unusable.
Created attachment 6002 [details] [review] [SIGNED-OFF] Bug 6854: Correct a double password encryption problem in import_borrowers.pl When the CSV file has no password column and no default value was set for the password : If we try to modify an existing user, the password from the BD is sent to ModMember, which then encrypts the already-encrypted password a second time. http://bugs.koha-community.org/show_bug.cgi?id=6854 Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Confirmed bug on current master. 1) Import new patron with password provided > OPAC login works 2) Overwrite patron record, password provided > OPAC login works 3) Overwrite patron record, password not provided Before patch: OPAC login broken, password in database changed After patch: OPC login works with same password as before
I have updated the severity - destroying existing patron passwords seems critical to me.
Simple patch, well tested, fixes a critical login issue. Marking Passed QA.
Pushed, please test
Created attachment 6064 [details] testing CSV file This CSV file is helpfull to test the bug is fixed