The site is deployed on the platform OJS 3.
Users successfully complete the registration process. But nothing happens when they try to login. The system does not generate any error, but the authorization process does not take place. The page is simply refreshed. This problem was noticed in two browsers: Opera and Google Chrome.
Hi @Natalia_Yena,
You might need to turn off the session_check_ip option in config.inc.php. See What is "session_check_ip"? for details.
Regards,
Alec Smecher
Public Knowledge Project Team
Alec Smecher,
in config.inc.php file, session_check_ip line is set to off. But there is a problem.
We also had this problem. I tried to fix as suggested, but none of the following worked on our system…
- clear browser cookie and cache
- session_ip_check = off
- session_cookie_name CHANGE
I did fix the problem by setting session_lifetime = 0 and this reset the stuck session successfully.
–
Steve Roe
steve@henleycloudconsulting.co.uk
Despite my optimism that setting session_lifetime = 0 would solve this problem, it continues to persist on our site. We are handling around 500 submissions per year / 1000 views per day, and the problem only occurs from time to time. But it persists and our ability to resolve it does create an impression of poor quality service to some of our most regular/valued editors.
We have now pinned down the root cause to bad cookie conflicts (maybe around www and or ‘.’ dot behaviour) with some reproducibility and we are confident that if a stuck login occurs that a browser cookie reset will resolve the problem (until it recurs). So there is a (fairly unattractive) workaround. (here are details How to Clear the Cache and Cookies in Your Web Browser | Information Technology Services )
I recently had the opportunity to spend some time to attempt to isolate the root cause, but the problem is quite elusive and all I have been able to do is to document the fixes that we have tried unsuccessfully. Since we have determined that this is an OJS bug, I have opened a bug issue with my detailed report attached here:- Authorization (Login) · Issue #7588 · pkp/pkp-lib · GitHub
I am hoping that this re-post will bump this issue up the OJS priority stack since it will need core dev knowhow to fix it!
Our session_cookie config is:
Currently we are running OJS 3.3.0.6 on PHP 7.3.33
@SteveRoe, I’ve closed the Github issue until we can determine here what’s happening or whether there’s a configuration solution; until we can reproduce the issue or isolate it from e.g. hosting configuration there’s not much we can do on our end.
Can you write a little more about the conflicting cookies? What characteristics do they have?
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher Alec - my guess is that you didn’t pick up that I have attached a 7 page Technical Bug Report to the github issue (with screen shots, elaboration of various potential causes, etc.)… if you did get a chance to read it then please can you guide me what additional information I can provide. Really appreciate your thoughts on this and anything else we might try!! ~steve
Hi @SteveRoe,
You’re right, I did miss the attachment.
I think this is related to an interaction between your subdomain and possibly virtual hosting configuration and OJS; there are enough OJS users/hosts out there (including virtual hosting users) that I don’t think it’s 100% implicit to the software or we’d have other reports. SFU’s own hosting operation uses virtual hosting quite extensively and we haven’t encountered this.
I share your suspicion that it’s a problem with two warring cookies whose configuration is slightly different but not enough to disambiguate them for delivery in the way OJS expects. I’ve seen this happen before with paths (which led us to add the session cookie path configuration option) but in your case I think it’s subdomains rather than paths.
I recommend working to ensure that your OJS site can only be delivered via one “canonical” URL, rather than ambiguously via several. This is a recommended practice for SEO (see e.g. Multiple URLs for the same page | SEO Forum | Moz). You can use a permanent redirect header to send users who visit the non-preferred URL over to the preferred one. (See e.g. mod_rewrite docs.)
I suspect this will solve the cookie problem in the bargain.
Thanks,
Alec Smecher
Public Knowledge Project Team
Hi Alec - aha! Thanks for the steer – I will take a look in that direction, but have little control over the mod_rewrite due to the virtual hosting package we use ;-(
~steve
This topic was automatically closed after 12 days. New replies are no longer allowed.