# Can't access the PrestaShop back office

> "Invalid token", a page that keeps reloading, credentials rejected even though they're correct: access to the PrestaShop admin is a single point of failure. Without it, you can't manage orders, stock or prices.

- Source canonique : [https://allaux.fr/en/prestashop/back-office-inaccessible](https://allaux.fr/en/prestashop/back-office-inaccessible)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Empty var/cache (1.7, 8, 9) or cache/smarty (1.6) over FTP, then delete the site cookie in your browser: that clears most invalid security token loops. If the redirect loop persists, compare the domain stored in the ps_shop_url table with the address actually being called, and check that COOKIE_KEY in app/config/parameters.php (1.7, 8, 9) or config/settings.inc.php (1.6) has not changed.

## Why the back office locks up

The PrestaShop back office relies on a system of tokens and cookies tied to an encryption key specific to each install, the COOKIE_KEY defined in app/config/parameters.php (1.7/8) or config/settings.inc.php (1.6). If this key changes between two environments, or if the ps_employee table holds an out-of-sync token, login fails with an "Invalid token" message or simply bounces back to the login page.

Redirect loops usually come from a conflict between the URL declared in the ps_shop_url table (domain and SSL domain) and the URL actually used by the browser, often after a domain name change, a move to HTTPS, or a backup restored on a different server.

Finally, a badly uninstalled admin module can leave an orphaned entry in ps_tab or ps_menu, causing an error when a menu tab is clicked.

## What I see regularly

- "Invalid token, please reload the page" message on a loop
- Endless redirect between /admin and the login page
- Credentials rejected even though they're correct, or a forgotten password with no reset email received
- Back office menu incomplete, or a tab that errors on click
- Access that works over HTTP but not HTTPS, or the other way round
- A renamed admin folder that's lost its access

## How I restore access

1. **Checking the cookie key** — I compare the COOKIE_KEY in the configuration file with what the current session expects, and check it wasn't changed by mistake during a file transfer.
2. **Checking the shop URLs** — I check the ps_shop_url table and the SSL settings (PS_SSL_ENABLED) to make sure they match the domain actually being served.
3. **Targeted reset** — If needed, I regenerate an employee password directly in the database with the correct hashing algorithm, without touching other accounts or orders.
4. **Menu cleanup** — I fix or rebuild the ps_tab entries tied to a removed module, so the back office menu becomes consistent again.

## Don't rename the admin folder under pressure

> Renaming the /admin folder without updating internal links (notification emails, employee bookmarks) can add a second lock on top of the first. I prefer to diagnose before touching the structure.

## Most frequent causes

- **Hosting migration** — The database was restored on a new server, but the configuration file still points to the old key or the old domain. ([/prestashop/migration/changer-d-hebergeur](/prestashop/migration/changer-d-hebergeur))
- **Forced HTTPS switch** — The SSL certificate was enabled on the server without updating PS_SSL_ENABLED or the URLs in the database, breaking the redirect. ([/guides/passer-site-en-https](/guides/passer-site-en-https))
- **Badly uninstalled third-party module** — A back office tab or widget stays referenced in the database even though the module's files were deleted. ([/prestashop/problemes/module-refuse-installation](/prestashop/problemes/module-refuse-installation))

## Related pages

- **Cannot log in to the admin area** — The same symptom seen more broadly: WordPress, PrestaShop and the causes they share. ([/problemes/connexion-administration-impossible](/problemes/connexion-administration-impossible))
- **PrestaShop emails not received** — When the password reset email never arrives, the same sending configuration is often to blame. ([/prestashop/problemes/emails-confirmation-commande-non-recus](/prestashop/problemes/emails-confirmation-commande-non-recus))
- **Misconfigured multistore** — Each shop has its own domain in ps_shop_url: one mismatch is enough to cause a redirect loop. ([/prestashop/problemes/multiboutique-configuration](/prestashop/problemes/multiboutique-configuration))
- **Clearing the PrestaShop cache** — Which folders to delete depending on the version, and what to leave alone. ([/guides/vider-cache-prestashop](/guides/vider-cache-prestashop))

## FAQ

### Will I lose my employees' rights in the database?

No, I work on the existing accounts. I only recreate an account if the ps_employee table is genuinely corrupted, and in that case I leave the other users untouched.

### Is the storefront (front office) affected too?

Usually not: a back office lockout doesn't stop customers ordering. I always check the front end in parallel to confirm sales are still going through.

### What access do I need to give you?

FTP or SSH access to read the configuration files, and access to the database. If you still have a working employee account, its credentials help too.

### Why haven't I received the password reset email?

Usually because the outgoing mail server (SMTP) is misconfigured or blocked, not because of an account issue. I check the mail configuration alongside access.

### How long does it take to regain access?

An invalid token or a redirect loop is the kind of block that gets sorted the same day once server access is available. What stretches the timeline is rarely the fix itself: it is getting the FTP or SSH credentials back from the host.