Closed AmericanLegacies closed 2 years ago
On the sites that do not allow logins: does this happen for ALL admins? What about other users (non admins)? Are they able to login?
What happens when you login: do you get any message? Such as "wrong password" or does it just refresh?
Do you get this error: "Your login details don't match any registered user" ?
Moc is right. At first, check if the user (admin) is able to log in via standard login.php With login.php there is more debug information on what is wrong. And this way you will confirm if the user account is correct.
If login.php works and admin.php does not, the problem is in admin rights (regardless of the message).
@AmericanLegacies Which version of e107 did you upgrade from? I'm happy to troubleshoot with you in real-time. I'll be available most of today. Please message me directly here: https://gitter.im/CaMer0n
MOC, thanks for the questions. The sites that do NOT allow logins, happens with multiple admins and users. The only message to the admins is to the effect of wrong password, for ALL admins. On the users that can not log in, there seems to be a problem with them receiving emails from the program, yet they can receive emails from other sources.
CaMerOn, we upgraded from 2.3.0 to 2.3.1
@AmericanLegacies Alright. I recommend checking in with Cameron on Gitter. He can real-time troubleshoot the issue with you.
Update: After spending hours today, I now have a bit more information available. I checked one of our sites that only has two admins and no users, because they are all registered for a “forum” in one of the sub directories. Neither one of the admins can log into that site.
So, on that site, I tried to use the front end for a lost password and the only thing I received was an email stating:
“Someone with an ipaddress **** attempted to reset the main admin password.”
The rest of the email was blank.
I went to another site, where I could not log in as admin and WAS able to log in as a user AND even reset the USER password, but since that user account did not have admin privileges, it was no use except letting me know that users can still log in on that site.
I can not believe there is not a secure way for the admin to access the site through the database or editing some script hidden somewhere on the server.
If may be our only recourse is to back up the databases and move all of them to a different CMS program. I sure hate to leave, but out of the 30 plus programs we use, e107 has the best search engine results, getting us #1 in our class, but on the flip side, the support is the hardest to find.
Please find real-time support with the developers through the Gitter chatroom, as advised twice now.
The behaviour of trying to reset the main administrators password you described is indeed the way it is programmed. I would be interested however, in seeing what happens when you try to reset the other admins password (not the MAIN admin).
Also, did you try changing the password in the database field with an md5 value? Upon login, the password is then encrypted properly again but at least it may be a way to get in.
Also, please answer the question by @Jimmi08. Is there a difference between logging in directly on /login.php or /e107_admin/admin.php?
@AmericanLegacies Any feedback on this? Did you try to reach out in the chatroom to get real-time help solving the issue?
I was able to cause a login to fail silently by unsetting the user_tracking
core pref. This doesn't result in an error, but the session doesn't get loaded on the next page, and so it looks like the user is not logged in.
This commit appears to have been a partial fix, but to complete it, I think the following patch is needed:
diff --git a/e107_handlers/user_model.php b/e107_handlers/user_model.php
--- a/e107_handlers/user_model.php (revision b4ded935b7bc6631a0d86013981895cd345bdcf4)
+++ b/e107_handlers/user_model.php (date 1640554943817)
@@ -2112,7 +2112,7 @@
{
$this->_session_data = null;
$this->_session_key = e107::getPref('cookie_name', 'e107cookie');
- $this->_session_type = e107::getPref('user_tracking', 'cookie');
+ $this->_session_type = e107::getPref('user_tracking', 'session');
if('session' == $this->_session_type && isset($_SESSION[$this->_session_key]) && !empty($_SESSION[$this->_session_key]))
{
Otherwise, e107 might try looking for the cookie to log in when it should be looking for the session.
I agree. @CaMer0n What do you think?
Guys, I just noticed this today... maybe related. The site is using cookies with custom name. (in pref cookies/sessions - cookies is selected) . I checked it in Console, it is saved correctly, expiration time = session.
But logout is not working, the user is still login in until the browser is not closed. Cookie is still there.
After reopening browser, user is not logged in.
@AmericanLegacies Would you be open to trying the above patch on one of the sites which is failing on login?
I committed the patch because I'm pretty sure it's necessary.
We have over a dozen sites running e107 and after upgrading to v. 2.3.1 at least 6 of them will not allow the admins to log in.
This effects multiple admins. The some sites that are working, and allow login’s are on the same server and some sites that do not allow log in’s.
These are working production sites that we NEED to get into ASAP.
We even tried changing the admin password in the db for one site as a test and it did not work. So if anyone has any suggestion on how we can regain access to our sites, please let me know.
BTW, we don't use any ad-ons and the only change we have made is the use of a "magazine" template that we use on multiple sites, but again, some of those sites WILL allow us to log in and others do not. Thanks