Login loop with OJS 3.2.1-2 in OVH


I have installed the OJS module under an OVH host. And I run into some caching problems. Can someone give me some help. I have finally managed to complete and create the magazine, with the Opera browser. But I don’t understand the reasons.

A colleague (@marc) has helped me change the site from production to development.

  • Regenerate and clean CDN.

  • The log has broken.

But suddenly the web stops going well and does not allow you to login.

I look forward to your help.

Version OJS:

@gardbeat, you need to be more specific about the error you get instead of your suspects.

To make it more clear, let me explain you are now in a login loop (I change your title to clarify). When you login, instead of going to the admin backend, you are redirected again to login page.

More info about the context:

  • OJS installed is the last release (3.2.1-2), from the tarball in the web.
  • PHP log is clean.
  • Server is in OVH and is a php 7.3.
  • No special .htaccess rules applied.
  • OVH offers a “CDN” service… that in confidence, I don’t understand much.
  • No modifications in config.inc.php

As said, I took a look but I can’t understand why it didn’t work as expected.

@marc, thanks for de tecnichal aclaration.

After setting php to 7.3 the issue is still there.

I can see 2 possible causes:

  • OJS configuration: wrong paths, urls, protocols and so on…
  • OVH configuration: CDN related (issues with the middle layers or with the fact of getting data from different severs) or OVH settings (dev vs production, firewalls, etc).

Forcing OJS to work on httpS and setting ovh to production with phpcgi did the job.

If using the browser’s dev tools, is there anything strange in the signIn request? E.g., I’m getting:

Request URL: http://ojs-3.2.1-2.test/index.php/psp/login/signIn
Request Method: POST
Status Code: 302 Found

and in the response headers I see:

Location: http://ojs-3.2.1-2.test/index.php/psp/submissions

which is the path for redirection.
Is it the same in your case?

Also, what about server access log, does it contain anything relevant?

Does this mean the login issue was resolved by applying these changes?


I’m on vacations now, so sorry for the lag.

@ojs_univie yes. Forcing httpS + setting base_url did the job.

@Vitaliy I can tell you for sure because now that httpS is forced, all is working fine.
As far as I can see, http is redirected (code 302) to httpS and urls are build in a consistent way.
Take a look to it if you like.

Server log is clean.


In my case, I couldn’t log in dashboard although I entered the username and password correctly. The effected browsers were Chrome and Firefox. No trouble occured via Safari. Later, I have read a discussion about this issue, and solved my problem by clearing the browser cache.

I hope this helps.

I explained this error to the authors by this message;

If you have entered your journal username and password correctly but you are having trouble logging in to the journal panel, you need to clear your browser’s cache. To troubleshoot the problem of being unable to log into the user dashboard, you should clear the browser cache by pressing CTRL + SHIFT + DELETE (COMMAND+SHIFT+BACKSPACE on a ) keys simultaneously in Google Chrome and Mozilla Firefox browsers, especially by selecting Cookies and Other Site Data option on the Clear Browsing Data screen.



Now it’s more clear to me. I’ve encountered a similar problem on the OJS instance where I’ve made modifications regarding separate URLs for each locale (locale-specific subdomains). The solution was to play around with cookie name. I suspect a similar thing may happen if there are several OJS instances under one domain and changing session_cookie_name, as described in that thread, should work.

1 Like