You Enter Your Credentials. OJS Sends You Right Back to the Login Page.

You go to your OJS journal. You enter your username and password. You click login. OJS appears to accept your credentials, and then sends you straight back to the login page. Empty fields. No error message. No explanation.

SponsoredNeed OJS hosting that scales?

Managed OJS hosting with backups, SSL, and priority support for scholarly publishers.

See pricing plans →

You try again. Same result. You clear your browser cache. Still the same. You try a different browser. Still looping. You check your password reset email and confirm the credentials are correct. And still, every time you log in, OJS bounces you right back to where you started.

The OJS login loop or redirect error is one of the most frustrating problems in Open Journal Systems because it looks like a password problem but almost never is. Your credentials are correct. The problem is somewhere between OJS accepting your login and maintaining your session, and that gap is where several very different technical issues can hide.

This guide covers every known cause of the OJS login loop and redirect error, how to identify which one is affecting your journal, and the exact fixes, written by OJS specialists who resolve this problem regularly across installations in 20+ countries.

If your editorial team is locked out right now and you need access restored fast, visit ojsguru.com for priority OJS support.

How OJS Login Works, and Where It Breaks

Understanding why OJS login loops happen requires a quick look at what OJS actually does when you log in.

When you submit your credentials, OJS does three things in sequence:

Authentication, OJS checks your username and password against the database. If they match, authentication succeeds.

Session creation, OJS creates a session record in the database and sets a session cookie in your browser. This cookie is what tells OJS who you are on every subsequent page load.

Redirect, OJS redirects you to your dashboard or the page you were trying to access.

A login loop means authentication is succeeding, OJS accepts your credentials, but the session creation or the cookie setting is failing. When OJS tries to load your dashboard, it checks for your session cookie, finds nothing, and assumes you're not logged in. So it sends you back to the login page.

This failure can happen at several different points in that chain, and each point has a different cause and a different fix.

Step 1: Gather Basic Diagnostic Information

Before diving into fixes, collect these details, they'll tell you which cause is most likely:

When did the login loop start? Did it appear after an OJS upgrade, a server change, an SSL certificate update, or a domain change? Timing often points directly to the cause.

Who is affected? Is the loop affecting all users or just specific accounts? All browsers or just one? If only one user is affected, the problem is likely account-specific. If everyone is locked out, the problem is server or configuration level.

What does the URL show during the loop? Watch the browser URL bar as you log in. Note any unusual redirects, especially between http:// and https://, between www. and non-www versions of your domain, or between different subpaths.

Is there an error message anywhere? Check your OJS error log at /cache/logs/errors.log and your server PHP error log. Even if your browser shows nothing, the logs may contain session-related errors.

These four pieces of information narrow down the cause significantly before you try any fix.

Cause 1: base_url Mismatch in config.inc.php

This is the most common cause of OJS login loops, and the most frequently overlooked. OJS uses the base_url setting in config.inc.php to set session cookies. If the base_url doesn't exactly match the URL your browser is using to access the journal, the session cookie is set for the wrong domain and your browser ignores it on the next page load.

Common mismatch scenarios:

  • base_url is set to http://yourjournal.com but you're accessing the journal via https://yourjournal.com
  • base_url is set to https://www.yourjournal.com but you're accessing via https://yourjournal.com (no www)
  • base_url still points to a staging domain or localhost after a server migration
  • base_url includes a trailing slash that conflicts with OJS routing

How to identify this cause:

Open config.inc.php and find:

base_url = "http://yourjournal.com"

Compare this exactly to the URL in your browser's address bar when you're on the login page. Any difference, protocol, subdomain, trailing slash, path, will cause a login loop.

How to fix it:

Update base_url in config.inc.php to match exactly what appears in your browser address bar:

; Correct,  matches browser URL exactly
base_url = "https://yourjournal.com"

; Also correct if your journal is in a subdirectory
base_url = "https://yourjournal.com/ojs"

Save the file, clear your OJS cache, and test login immediately.

# Clear OJS cache after config change
rm -rf /path-to-ojs/cache/fc/*
rm -rf /path-to-ojs/cache/t_cache/*

Cause 2: HTTP to HTTPS Redirect Conflict

After adding an SSL certificate or migrating to HTTPS, many OJS installations develop a login loop caused by a conflict between the SSL redirect and OJS's session cookie settings. The session cookie is set on the HTTP version of the domain but the SSL redirect immediately sends the browser to the HTTPS version, where the cookie doesn't apply.

How to identify this cause:

The login loop started after you installed an SSL certificate or enabled HTTPS. Watching the URL bar during login shows a brief switch between http:// and https://.

How to fix it:

Step 1, Update base_url to HTTPS:

base_url = "https://yourjournal.com"

Step 2, Force HTTPS in .htaccess:

Add this to your OJS .htaccess file to ensure all traffic goes to HTTPS before OJS sets any cookies:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Step 3, Set cookie_secure in config.inc.php:

; Force session cookies to require HTTPS
session_cookie_secure = On

Step 4, Clear browser cookies and OJS cache:

After making these changes, ask all affected users to clear their browser cookies for your domain before logging in again. Old HTTP cookies will conflict with new HTTPS cookie settings.

Cause 3: Session Storage or Database Session Table Problems

OJS stores session data in your database, specifically in the sessions table. If this table is corrupted, locked, or has accumulated too many stale session records, new sessions can't be written correctly, causing every login attempt to fail silently.

How to identify this cause:

Your error log shows database errors related to the sessions table, Table 'sessions' is marked as crashed, Lock wait timeout exceeded, or Duplicate entry errors. Or the problem appeared after a database crash or interrupted OJS upgrade.

How to fix it:

Option A, Clear all sessions via database:

-- Connect to your OJS database
-- Delete all existing sessions (all users will need to log in again)
DELETE FROM sessions;

Option B, Repair the sessions table:

REPAIR TABLE sessions;
OPTIMIZE TABLE sessions;

Option C, Via phpMyAdmin:

  1. Open phpMyAdmin and select your OJS database
  2. Find the sessions table
  3. Click Operations and run Repair table
  4. Then click Empty to clear all stale sessions

After clearing sessions, test login immediately. If the loop persists, the sessions table itself may need to be recreated, check the OJS database schema for your version for the correct table structure.

Cause 4: Cookie Domain or Path Mismatch

OJS sets session cookies with specific domain and path attributes. If these attributes don't match your current domain configuration, particularly after a domain change, a subdomain migration, or a subdirectory path change, and the browser will reject the cookie as invalid for the current URL.

How to identify this cause:

Open your browser's developer tools (F12), go to the Application tab, and look at Cookies for your domain. After logging in, check whether a session cookie is being set. If no cookie appears after login, or if the cookie domain shows a different domain than what you're currently on, this is the cause.

How to fix it:

In config.inc.php, find and update the cookie settings:

; Set to your domain without www prefix
session_cookie_domain = ".yourjournal.com"

; Set to the path where OJS is installed
; Use / if OJS is at the root of your domain
session_cookie_path = "/"

If OJS is installed in a subdirectory, for example https://yourjournal.com/ojs/, set:

session_cookie_path = "/ojs/"

After updating these settings, clear OJS cache and ask users to clear their browser cookies before testing.

Cause 5: PHP Session Configuration Issues

OJS relies on PHP's session handling system. If PHP session settings on your server are misconfigured, particularly the session save path, session lifetime, or session handler, OJS can authenticate you successfully but fail to persist the session between page loads.

How to identify this cause:

Your error log shows PHP warnings like session_start(): Failed to read session data, open(/tmp/sessions, O_RDWR) failed, or Cannot send session cookie, headers already sent.

Common PHP session problems:

Session save path not writable:

# Check current session save path
php -r "echo session_save_path();"

# Ensure it's writable
sudo chmod 777 /var/lib/php/sessions
# or
sudo chmod 777 /tmp

Headers already sent error:

This means OJS is trying to set a session cookie after output has already been sent to the browser, usually caused by a whitespace or BOM character at the beginning of a PHP file, often config.inc.php or a plugin file.

# Check for BOM characters at start of config.inc.php
file /path-to-ojs/config.inc.php
# Should show "ASCII text" not "UTF-8 Unicode (with BOM)"

Open the file in a BOM-aware editor (VS Code works well) and remove the BOM if present.

Session lifetime too short:

; In php.ini or .htaccess
session.gc_maxlifetime = 3600
session.cookie_lifetime = 0

Cause 6: Cloudflare or Reverse Proxy Interference

If your OJS journal sits behind Cloudflare, an Nginx reverse proxy, or a load balancer, these intermediary layers can interfere with cookie handling and session management in ways that cause login loops, particularly when SSL termination happens at the proxy level rather than at the OJS server.

How to identify this cause:

The login loop only started after you added Cloudflare or changed your server's proxy configuration. Accessing your journal directly via its IP address (bypassing Cloudflare) resolves the login loop.

How to fix it for Cloudflare:

Step 1, Ensure SSL mode is Full (Strict): In your Cloudflare dashboard, go to SSL/TLS and set the mode to Full (Strict), not Flexible. Flexible SSL causes exactly this kind of login loop because Cloudflare connects to your origin server over HTTP while your browser connects over HTTPS.

Step 2, Disable Cloudflare caching for login pages: Add a Cloudflare Page Rule:

URL: yourjournal.com/index.php/index/login*
Setting: Cache Level = Bypass

Step 3, Add trusted proxy support to OJS config:

; Tell OJS to trust proxy headers
trust_x_forwarded_for = On

For Nginx reverse proxy:

Ensure your Nginx config passes the correct headers to OJS:

location / {
    proxy_pass http://your-ojs-backend;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

Cause 7: Specific User Account Problem

Sometimes a login loop affects only one user account while everyone else can log in normally. This points to a problem with that specific user's account record in the database, a corrupted session token, an incorrect role assignment, or an account flag that OJS interprets as invalid.

How to identify this cause:

Other users can log in without problems. Only one or a few specific accounts are affected. The problem persists even after the affected user clears their browser cookies and tries a different browser.

How to fix it:

Option A, Reset the affected user's password via database:

-- Generate a new password hash for the user
-- Replace 'newpassword' with the desired password
UPDATE users 
SET password = MD5(CONCAT(username, ':', 'newpassword'))
WHERE username = 'affected_username';

Note: OJS 3.x uses a different password hashing method. Use the OJS admin panel to reset the password if possible, go to Administration → Site Users → [username] → Edit User → Reset Password.

Option B, Clear the user's active sessions:

-- Delete sessions for a specific user
DELETE FROM sessions WHERE user_id = (
    SELECT user_id FROM users WHERE username = 'affected_username'
);

Option C, Disable and re-enable the account:

In the OJS admin panel (logged in as a different admin account), go to Administration → Site Users, find the affected user, disable their account, save, then re-enable it and save again. This clears certain account flags that can cause login failures.

Cause 8: OJS Installed in Subdirectory With Incorrect Path Configuration

When OJS is installed in a subdirectory, for example https://yourjournal.com/journal/, path configuration errors frequently cause login loops. The session cookie path doesn't match the subdirectory path, so the browser sends the cookie on root-level requests but not on subdirectory requests where OJS actually lives.

How to identify this cause:

OJS is installed in a subdirectory. The login loop started after a domain restructuring or server migration where the subdirectory path changed.

How to fix it:

In config.inc.php:

; Base URL must include the subdirectory path
base_url = "https://yourjournal.com/journal"

; Cookie path must match the subdirectory
session_cookie_path = "/journal/"

In your .htaccess file, ensure the RewriteBase matches your subdirectory:

RewriteBase /journal/

Cause 9: Browser-Specific Cookie or Security Settings

Occasionally an OJS login loop is caused not by the server but by the browser's own security settings, particularly third-party cookie blocking, strict SameSite cookie policies, or aggressive privacy extensions.

How to identify this cause:

The login loop only affects one specific browser or one specific user's machine. Other browsers on the same computer or other computers work fine. The affected browser has privacy or security extensions installed.

How to fix it:

Ask the affected user to:

  1. Try logging in using an incognito or private window, this disables most extensions
  2. Clear all cookies and site data for the journal domain
  3. Temporarily disable privacy extensions (uBlock, Privacy Badger, etc.) and test
  4. Check browser settings for third-party cookie blocking and whitelist the journal domain

For the server side, update SameSite cookie settings in config.inc.php:

; Set SameSite policy for session cookies
; Options: Lax, Strict, None (None requires Secure)
session_samesite_cookie = "Lax"

Using Lax is the recommended setting for OJS, it balances security with compatibility across modern browsers.

Quick Diagnostic Checklist

Work through this in order:

  • Check base_url in config.inc.php: does it exactly match your browser URL?
  • Check whether login loop started after SSL/HTTPS change
  • Watch URL bar during login, any http/https or www/non-www switching?
  • Check OJS error log at /cache/logs/errors.log
  • Open browser dev tools, is a session cookie being set after login?
  • Test in a different browser and incognito mode
  • Test whether all users are affected or just specific accounts
  • Check whether Cloudflare or a proxy is in front of your OJS server
  • Clear sessions table in database and retest
  • Check PHP session save path is writable
  • Verify session_cookie_domain and session_cookie_path match your setup

When to Call in a Professional

The OJS login loop is fixable in most cases by working through the checklist above. But some situations call for professional help:

  • Your entire editorial team is locked out and a submission deadline is approaching
  • The loop appeared after a server migration with multiple configuration changes at once
  • You've verified all config settings are correct but the loop persists
  • The problem is affecting specific user accounts and database-level fixes haven't worked
  • You don't have server access to check logs or edit config.inc.php

OJS Guru resolves OJS login and session errors as a standard support service. Send us your journal URL and a description of when the loop started, and we'll diagnose and fix it, usually within one business day.

👉 Get a free consultation at ojsguru.com

Preventing OJS Login Loops Going Forward

Always update base_url after any domain or SSL change. This is the number one preventable cause of OJS login loops. Any time your domain, subdomain, protocol, or subdirectory path changes, update base_url in config.inc.php immediately.

Test login after every upgrade or server change. Make testing the login workflow the very first thing you do after any OJS upgrade, server migration, SSL update, or hosting change. Catching a login loop immediately after a change makes the cause obvious.

Document your OJS configuration. Keep a record of your base_url, session_cookie_domain, session_cookie_path, and HTTPS settings. When something changes on the server, you can compare the current config against your documented settings and spot mismatches instantly.

Use a consistent URL. Decide whether your journal uses www or non-www, http or https, and stick to it everywhere, in config.inc.php, in your SSL redirect rules, and in all published links to your journal. Inconsistency is the root of most session and cookie problems.

Summary

The OJS login loop or redirect error is never a password problem. It is always a session, cookie, or configuration problem, and every cause is identifiable and fixable. The nine causes covered in this guide account for the vast majority of OJS login loops in production:

  1. base_url mismatch in config.inc.php
  2. HTTP to HTTPS redirect conflict
  3. Session storage or database session table problems
  4. Cookie domain or path mismatch
  5. PHP session configuration issues
  6. Cloudflare or reverse proxy interference
  7. Specific user account problem
  8. OJS installed in subdirectory with incorrect path configuration
  9. Browser-specific cookie or security settings

Work through the diagnostic checklist, identify your specific cause, and apply the relevant fix. In most cases, the fix takes less than 15 minutes once you know what you're looking for.

If your editorial team is locked out and you need access restored quickly, contact OJS Guru at ojsguru.com. We fix OJS login problems every day and we'll have your journal accessible again fast.

OJS Guru is a professional Open Journal Systems service provider specializing in OJS installation, customization, migration, and technical support for research journal publishers in 20+ countries. Visit ojsguru.com to request a free consultation.