How To Fix the Persistent PrestaShop Back-Office Cookie & Session Login Loop

What Causes This Problem?

PrestaShop uses a two-part system to keep you logged in. First, a cookie is stored in your browser. Second, the server stores a matching session that holds your identity and permissions. When these two do not align, the back office assumes you are not authenticated and redirects you to the login page.

Start with the cheap and fast checks first. Most login loops come from a cookie setting or URL mismatch, not from deep server faults.

Quick Fixes

Try these steps in order. Most users resolve the login loop within the first few attempts.

1. Clear browser cookies for your shop domain. Close all back office tabs, delete cookies for the site, then reload the login page. This removes any stale authentication token.
2. Use a private or incognito window. This gives you a clean cookie jar and confirms whether an old cookie is causing the issue.
3. Disable browser extensions. Ad blockers and privacy tools can strip or alter cookies. Turn them off for your admin domain and retry.
4. Check that you are using the exact back office URL. If the shop has moved from HTTP to HTTPS, type the full HTTPS address manually rather than relying on a bookmark.
5. Remove the www prefix inconsistency. If you access yourshop.com but the cookie is set forwww.yourshop.com, the session will never match.
6. Restart your browser completely. Close every window, wait a few seconds, and reopen. This clears any in-memory session remnants.
7. Test from your mobile phone. Use a different network, such as mobile data, to rule out a corporate proxy or firewall interfering with cookies.
8. Reboot your web server if you own the hosting. This clears any corrupted PHP session files held in memory, such as those stored by Memcached or Redis.

If the loop persists, move to the diagnostic chapters below. Each one targets a single root cause.

Check the Back Office URL Configuration

The most frequent culprit is a mismatch between the domain stored in your PrestaShop settings and the domain you actually type in the address bar. After a domain migration or an SSL switch, this value can become stale.

If the configured URL points to the old domain, your browser receives a cookie for that old domain, which the new address never reads. You end up in a perpetual redirect.

• Go to Advanced Parameters > General in the back office.
• Compare the Shop URL fields with the address you are currently using.
• Ensure the protocol matches: if you browse with HTTPS, the saved URL must start with https://.
• If you cannot reach the back office at all, edit the ps_shop_url table in your database using phpMyAdmin and update the domain, domain_ssl, and physical_uri fields.

Once the URLs align, clear your cookies and reload. The session handshake should now complete without redirecting you to the login form.

Fix the Cookie SameSite: Site Attribute

Modern browsers treat cookies without a SameSite attribute as Lax by default. If your back office and front office run on different subdomains, the browser may quietly drop the session cookie and send you back to the login screen every time.

This became a widespread issue after browser vendors updated their cookie policies. PrestaShop versions released before those changes often lack the proper SameSite attribute in their session cookies.

• Open your shop's config/settings.inc.php file and locate the cookie-related constants.
• For most single-domain shops, SameSite=Lax is the safer permanent choice and rarely causes loop issues.
• If your setup genuinely requires cross-site requests, confirm you are serving the entire site over HTTPS before setting SameSite=Nonesince Chrome rejects None attributes on insecure connections.

After editing the file, clear your browser cookies completely and test the login again. This fix resolves a large share of login loops that appear after a Chrome or Firefox update.

Clear PHP Session Files on the Server

When browser cookies are not the culprit, the fault usually sits in PHP session files stored on your server. A corrupted or leftover session file can keep the back office in a loop even after you clear your browser.

PrestaShop stores these files in a dedicated directory. Deleting them forces the system to create fresh sessions on the next login attempt.

1. Connect to your server with an FTP client such as FileZilla, or open File Manager in your hosting panel.
2. Locate the PrestaShop root folder and find the var/sessions directory (or cache on older PrestaShop versions).
3. Delete the contents of the session folder. Do not delete the folder itself, only the files inside it, and never touch any index.php file inside.
4. Repeat the process on the var/cache folder to clear compiled files that can also stall the login.
5. Attempt to log in again with your usual credentials.

If your host stores PHP sessions in a central server directory instead of the PrestaShop folder, you may not have access. Contact your hosting provider and ask them to clear the PHP session files for your account. This is routine, and most hosts handle it quickly.

Adjust the Back Office Session Lifetime

A very short session timeout can log you out while working in the back office, which feels exactly like a login loop. PrestaShop lets you extend this window without touching code.

The default session lifetime may be too aggressive if you run long content updates or manage products slowly. Raising it gives you a comfortable working window.

1. Log in to the back office if you can still access it, or use the database method below if you cannot.
2. Go to Preferences and then General.
3. Look for the field labelled Back Office Session Lifetime and increase it from the default to a longer value, such as 480 minutes.
4. Save the changes and test the login again.

If you are completely locked out, update the value directly in the database. Open phpMyAdmin, find the ps_configuration table, locate the row for PS_BO_SESSION_LIFETIME and change its value to a higher number. Clear your browser cookies afterwards, and the login should work for several hours without dropping you.

Disable Server-Side Caching Temporarily

Server-side caching layers such as OPcache, Memcached, or Varnish can serve stale PHP scripts that break session handling. The login page you see may be cached from before a configuration change, so it still points to the old session logic.

This cause is more common on shared hosts that enable aggressive caching by default. A quick test isolates whether caching is interfering with your login.

• Log in to your hosting control panel and look for a caching section, often under Performance or Optimisation.
• Disable OPcache and any Memcached or Redis caching for a short test. If your host uses Varnish, ask them to put your domain on bypass.
• Clear the cache from your hosting panel after disabling these services.
• Attempt to log in to the back office. If it works with caching off, you have found the source of the loop.

Re-enable caching one service at a time to identify the specific layer that causes trouble. Then configure that service to exclude the admin directory from caching. In case you get into trouble at any stage, you can always count on the expert PrestaShop developers of FME Modules for quick guidance and support. 

Verify Your PHP Version and Settings

An outdated or unsupported PHP version can cause session handling to fail silently. PrestaShop releases specify minimum PHP requirements, and running an older version may trigger login loops, especially if your host upgraded PHP recently.

Session settings in your php.ini file also matter. If session.save_path points to a directory PHP cannot write to, the session never persists.

1. Check your PHP version in Advanced Parameters > System Information if you can reach the back office, or via your hosting panel.
2. Compare it against the minimum requirement for your PrestaShop version, listed in the official documentation.
3. If your version is outdated, switch to a supported one through your hosting panel. Most hosts offer one-click PHP version changes.
4. Verify the session.save_path directory exists and has write permissions for the web server user.

You can test session writing by creating a temporary PHP file that calls session_start() and writes a test value. If the file fails to read it back, your session configuration is broken.

Fix Cookie Domain and Path in the Database

PrestaShop stores cookie parameters in the database. If the cookie domain is set to a bare domain like .yourshop.com but you access the store via www.yourshop.com, some browsers will reject the cookie as third-party.

You can inspect these values directly in the database to verify they match your setup. Look at the ps_configuration table for entries named PS_COOKIE_DOMAIN and PS_COOKIE_PATH.

1. Open phpMyAdmin and select your PrestaShop database.
2. Run a query to locate the cookie configuration rows: SELECT * FROM ps_configuration WHERE name LIKE '%COOKIE%'
3. Update the PS_COOKIE_DOMAIN value to match your actual access domain, including the leading dot if you use subdomains.
4. Set PS_COOKIE_PATH to / if your shop runs from the domain root.
5. Clear your browser cookies and test the login again.

This fix matters most after a domain migration, when the old cookie domain may still be stored in your database.

Handle a Corrupted Admin Folder or File Overrides

PrestaShop's admin directory contains files that can become corrupted after a failed update or partial file transfer. A damaged file in the admin folder can log you out silently because the session handling code never completes its execution cycle.

Custom overrides in your classes or controllers directories can also interfere with authentication. A poorly written override may block the session check entirely.

• Compare your admin folder files against a fresh copy of the same PrestaShop version, downloaded from the official source.
• Replace any file that does not match, but keep your own custom parameters.php file intact since it holds your database credentials.
• Temporarily move any custom overrides out of the override folder to test whether they cause the login failure.
• If the login works without overrides, audit them for outdated session handling code before restoring.

This is a deeper fix that requires FTP access and patience. Only attempt it after confirming simpler causes are not responsible.

Step-by-Step Diagnosis Process

Work through this diagnosis sequence to narrow down the cause before making changes. Each step isolates one layer of the authentication chain.

1. Test in a private or incognito window. If you log in successfully, the issue is browser-side. Clear cookies and disable extensions.
2. Test from a different device. If the login works on your phone but not your desktop, the problem sits in your browser or local network.
3. Verify your back office URL. Confirm you are using the exact HTTPS address stored in PrestaShop settings, without a www mismatch.
4. Clear server session files. Delete the contents of var/sessions via FTP to rule out corrupted PHP sessions.
5. Check cookie configuration in the database. Inspect PS_COOKIE_DOMAIN and PS_COOKIE_PATH for mismatches.
6. Temporarily disable caching. Turn off OPcache, Memcached, or CDN caching for your admin path and retest.
7. Verify PHP version and session settings. Confirm you run a supported PHP version and that the session save path is writable.
8. Run server-side diagnostics. Use the commands in the next section to inspect PHP session activity and response headers.

Only move to the next step when the current one does not resolve the loop. This prevents you from making unnecessary changes to a working setup. 

Advanced Troubleshooting

When visual checks do not reveal the issue, use command-line tools to inspect what the server actually does during a login attempt. These commands give you concrete data instead of guesswork.

Run these from an SSH terminal connected to your hosting account. If session files are not being created, your PHP session save path is misconfigured, or the directory permissions are wrong. That single issue will produce a login loop no matter how many times you clear your browser cookies.

Server-side diagnostics take longer than a plugin-based fix, but they pinpoint the root cause rather than masking the symptom. If you are on managed hosting, open a ticket with your provider and share the output of these commands. Most hosts can adjust timezone settings or session save paths quickly once you show them the evidence.

How to Prevent This Problem

A login loop fix only sticks when you address the underlying configuration flaw. The following practices stop the issue from returning after a routine update or browser change.

• Keep your PrestaShop installation and PHP version updated to avoid known session handling bugs.
• Set a generous back office session lifetime in Preferences > General to prevent mid-work logouts.
• Exclude your admin directory from all server-side and CDN caching rules.
• Use a consistent domain without alternating between www and non-www versions.
• Test the back office login after every domain, SSL, server migration, or PrestaShop core update.
• Avoid sharing a single administrator account between multiple staff members, since session collisions are common.
• Keep a backup of your config/settings.inc.php file so you can quickly restore cookie constants if they change.

Conclusion

Fixing a PrestaShop back-office login loop comes down to realigning your browser's stored cookies with your server’s authentication data. By working through simple browser-side checks first and then moving on to database settings and server-side configurations, you can resolve the issue safely without risking any store data.

To keep your admin access seamless going forward, ensure your domain URLs match consistently, exclude admin directories from caching, and keep your server environment properly updated. Taking these preventive measures will secure your session logic and keep you logged into your store without further interruptions.