Random (?) login problems

Software Support
1

Hey there,

we are encountering random login problems for all types of user accounts (readers, journal managers, editors …).
One simply can never login using the Apple iPad default browser (the small safari version).
From time to time, unfortunately randomly, you cant login using the configurations Apple/OSX/Safari, Windows 7 / IE, Windows 7/Chrome, Windows 10 / Chrome.

Interestingly, if one submits a wrong user/password combination, the red error message pops up as it should. However, if one submits a correct login, the screen just returns to the login mode without further reactions. No error message, just behaving if nobody had entered anything there.

Has this been an issue before?
Would be grateful for any hint, because the last problem occured when demonstrating it in front of a conference in germany … ironically, as a last resort we tried the macbook of a colleague instead of the WinPc, and that worked (so we were lucky, finally … however, if one wants to subscribe and to read the issues and encounters that problem, it is a grave mischief…)

thank you -
Jesaiah

2

Were there any recent upgrade or architecture changes which could be relevant?

One common first consideration for “odd” login issues is the session_check_ip setting:

3

Hey there, thanks for the hint. We tried that, but it did not solve (all) problems. Strange enough, the colleague from the tech department reported to being able to login from the iPad/Safari, however, on mine I still have the same problem … entering username, entering password and being thrown back to the home > login screen without any further message …

Still thinking.

Thank you
CW

4

Try changing the session_cookie_name. This will invalidate all existing sessions, and create all new ones.

Does the problem persist across the same devices, regardless of what is used for the session cookie?

5

I encountered the same behavious when I tried to rewrite the url for an OMP press

Interestingly, if one submits a wrong user/password combination, the red error message pops up as it should. However, if one submits a correct login, the screen just returns to the login mode without further reactions. No error message, just behaving if nobody had entered anything there.

When i changed the value for base_url[journal] in config.ini.php to the longer url version it worked fine again. Maybe it’s a completly different error (as I noticed no browser exceptions) or maybe it helps (or maybe you have some hints how to solve my problem).

6

We are experiencing the same problem for our two instances of OJS 2.4.8.2. Logging in to the site with Firefox is no problem while several users experienced problems with Chrome and IE/Edge.

On my desktop I can login with Firefox 54.0 and IE 11 but not with Chrome. Any idea why this happens at all?

7

Hi @D_Schroeder_Micheel,

Have you tried any of the above suggestions? What were the results?

Regards,
Alec Smecher
Public Knowledge Project Team

8

The session check ip is set to off. Changing the session cookie name did not produce better results neither did changing the base url.

9

Hi @D_Schroeder_Micheel,

Can you reproduce this behavior with another installation of OJS, e.g. the testdrive installation?

Regards,
Alec Smecher
Public Knowledge Project Team

10

I was able to log into the testdrive installation. The main difference seems to be that our instances produce two cookies when browsed with Chrome:

Testdrive only produces one OJSSID-Cookie.

Could this be a reason?

11

Hi @D_Schroeder_Micheel,

One of those cookies appears to be limited to the domain, and one is also available to subdomains (the one with the leading .). I’m not sure why two are produced, but it’s possible that they are somehow conflicting. I’ve never heard of this issue before, which suggests that it’s somehow related to your environment – are you using rewriting, or a reverse proxy, or something like that?

The code that sets the domain for OJS session cookies is in lib/pkp/classes/session/SessionManager.inc.php – look for session.cookie_domain.

Regards,
Alec Smecher
Public Knowledge Project Team

12

Within Firefox only the one which includes all subdomains is set. We are not using rewriting or a reverse proxy as far as I know.

It is also rather confusing that Chrome gives out conflicting info considering the cookies. Because when further investigating the cookies via F12 only one OJSSID cookie is shown:

I am rather lost…

13

Hi @D_Schroeder_Micheel,

Do you mean you are now using, or you are not using?

Regards,
Alec Smecher
Public Knowledge Project Team

14

Hi @asmecher,

sorry! I edited my last post. We are not using rewriting or a reverse proxy AFAIK…

15

Hi @D_Schroeder_Micheel,

Is there a system administrator you could ask about rewriting or reverse proxy? This would be helpful to eliminate as a possible cause.

For what it’s worth, I haven’t heard of OJS behaving this way, and the version you’re running is extremely common. I can replicate the behavior with your site, i.e. logging in with Chromium (a variant of Chrome) doesn’t work on your server. However, I can log in fine with other installations of the same version of OJS with the same browser. That leads me to suspect either a server platform issue or a configuration or modification issue on your side. Unfortunately these are extremely difficult to debug remotely as I don’t have any knowledge about your server or modifications beyond what you can tell me.

Regards,
Alec Smecher
Public Knowledge Project Team

16

Hi @asmecher,

I contacted our provider to see if either a rewrite or a reverse proxy might be the problem. I will get back to you as soon as I get a mail. Thanks for yor help!

17

I have revisited the testdrive and found it to also produce TWO cookies in an analog fashion to our installation while I was still able to login.

image

image

From what our admin told us there are NO rewrites nor reverse proxies applied to our installation.

So, while it seems to be normal behaviour in my Chrome setup at least that OJS produces TWO cookies the remaining difference seems that the testdrive installation is in the folder /testdrive/ while our installation is directly in the root directory. Another difference would be that the “www.” seems to be hardcoded into the session.cookie_domain.

Couldn’t this be the problem right there?

18

Hi @D_Schroeder_Micheel,

I’d suggest removing any OJSSID cookies, and forcing your cookie path using the session_cookie_path setting in config.inc.php. If you have users experiencing this in the wild and don’t want to walk through deleting cookies with them, one option would be to change session_cookie_name in config.inc.php to something new as well – though this will force any users with existing sessions to log in again.

Regards,
Alec Smecher
Public Knowledge Project Team

19

I can’t find no session_cookie_path setting in config.inc.php. Could this be a new addition to OJS 3? We are still using 2.4.8.2.

20

Hi @D_Schroeder_Micheel,

Yes, it looks like this isn’t available in OJS2. The change that introduced it should be straight-forward to port back if you need it – see *7073* Add support for config-specified session_cookie_path (optional) · pkp/pkp-lib@67c96f2 · GitHub.

Regards,
Alec Smecher
Public Knowledge Project Team