After I updated my OJS base from 2.2.2 to 2.4.7-1 I can’t log in with admin account with OJS native authentication. I’ve executed the database update too.
I’ve tryed to change authentication from sha1 to md5, and from sha1 to md5 on Config.Inc.php. I’ve tryed to change the passaword from database like this post https://pkp.sfu.ca/support/forum/viewtopic.php?t=9530 with both sha1 and md5 (even I certain that we have been using sha1) and I’m still getting wrong password on authentication’s page.
I beliave that It’s trying to authenticate it from LDAP plugin, but I can’t find a way to change/check authentication type from code on Documentation.
Sorry if my english was not easy to understand. Thanks in advanced!
Although not being used before the update, there was a previous configuration for LDAP in auth_sources table. I tried deleting the row on the table, but the login failure persists.
Hi @rafaelmansilha,
What is the length of the password
column in the users
table in your database?
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher,
The lenght is set to 255.
| password | varchar(255) |
It used to work before the update. I’ve check here, and the passwords hash size are 40, what corresponds to SHA-1 encryption, and SHA-1 is set on config.inc.php.
I’ve have too reset the password with SHA-1 using the following query:
UPDATE users SET password=SHA1(CONCAT(username, 'newPasswordHere')) WHERE user_id = 1;
but still not work for Admin, and commum users.
They put me to take care of the system now, but a friend who took care (put out fires), informed me that she beliave that our system does not work with LDAP. And that long ago, they tried to configure LDAP in the application, but did not work out, then used the native OJS system. She also informed me that a while ago they did an update on the database, and for some reason it started doing user authentication through LDAP, but them fix the problem through the application (what I can’t try to do, because admin login fails).
As a test I deleted one “}” from LDAP plugin code, and try to log with the admin user. The Apache log accused an error in the LDAP code that I changed. So, it’s using the LDAP plugin to authenticate the admin user’s instead native authentication system, right?
Thanks in advanced!
Rafael Mansilha Murta
Universidade Federal do Tocantins.
Hi @rafaelmansilha,
The column length is as it should be, and 40-character hashes are OK. Make sure you use the same encryption hashing algorithm in your new install that you used to use in the old one. As you log in with user accounts you’ll see the password
column’s contents change to longer hashes – that’s expected behavior.
It does sound like an LDAP problem is a likely cause. Do you want to completely disable LDAP use, or do you still need it for something?
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher,
At the moment our ojs does not authenticate users with LDAP, but it is likely that in the future we will try to integrate with our university LDAP, if possible. But the priority at this present moment is to upgrade to the latest version of OJS.
If possible, I’d like to completely disable the LDAP now, but in a way that we can try to use it later.
Thanks in advanced!
Rafael Mansilha Murta
Universidade Federal do Tocantins.
Hi @rafaelmansilha,
To get all users to authenticate using the OJS database, try…
UPDATE users SET auth_id=NULL, auth_str=NULL;
DELETE FROM auth_sources;
Back up your database before doing this, of course.
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher,
I’ve tryed to run the query comands, and it’s work fine, but still not gettin acess to admin, or others users (wrong login/password). I’ve renamed the LDAPAuthPlugin.inc.php to see if it was still using LDAP class, but I get no error on apache log, so I believe that it’s not using LDAP anymore.
Thanks in advanced!
Rafael Mansilha Murta
Universidade Federal do Tocantins.
Hi @rafaelmansilha,
What happens if you try using the reset query that you quoted above?
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher,
mysql> UPDATE users SET password=SHA1(CONCAT(username, 'newPasswordHere')) WHERE user_id = 1; Query OK, 0 rows affected (0.07 sec) Rows matched: 1 Changed: 0 Warnings: 0
Thanks in advanced!
Rafael Mansilha Murta
Universidade Federal do Tocantins.
Hi @rafaelmansilha,
And – just checking – the value of the encryption
setting in config.inc.php
is sha1
?
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher,
No problem heres the code:
; The encryption (hashing) algorithm to use for encrypting user passwords ; Valid values are: md5, sha1 ; Note that sha1 requires PHP >= 4.3.0 encryption = sha1
Thanks in advanced!
Rafael Mansilha Murta
Universidade Federal do Tocantins.
Hi @rafaelmansilha,
Are you getting “login failed” type messages, or just being sent back to the login form?
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher,
I’m being sent back to the login form, and in the login page there is “wrong password/user” type messages.
Alec, can you tell me where the code that do the native login are? I’d like to check if they matches with the original code of the version 2.4.7-1. Perhaps the person who was responsible to take care of the project has edited it.
Thanks in advanced!
Rafael Mansilha Murta
Universidade Federal do Tocantins.
@asmecher, There is a way to debug login process?
Hi @rafaelmansilha,
I’d suggest working through the login
function in classes/security/Validation.inc.php
. [Edited: previously suggested incorrect lib/pkp base directory. -AS]
Regards,
Alec Smecher
Public Knowledge Project Team
1 Like
Hi @asmecher,
I’ve managed to solve it! I ran a diff in my code with the clean version 2.4.7-1 and indentifiquei failure in classes/security/Validation.inc.php
. Actually I did not find the lib/pkp/classes/security/Validation.inc.php
that you suggested.
In any case, the failure was caused by a change made in 2009 in an attempt to make the application work with LDAP.
Thanks for all your attention!
Rafael Mansilha Murta
Universidade Federal do Tocantins.
Hi @rafaelmansilha,
Sorry, my typo – classes/security/Validation.inc.php
is correct.
Glad to hear you got it going. You might consider doing a recursive diff against the stock version – if I’m orienting myself on an unfamiliar install I’ll often start with that.
Regards,
Alec Smecher
Public Knowledge Project Team
1 Like