Available for projects & agency overflow · Quick reply, from the person who does the work

Send a message contact@allaux.fr
FR EN TR
allaux.
Emergency Discuss my project

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.

Describe my issue Send a message

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.

Most frequent causes

Related pages

Describe your need in one minute

A few targeted questions so I can reply with an estimate rather than another questionnaire.

symptome
declencheur
front
acces-bdd (facultatif)
Please provide an email or a phone number so I can get back to you.

Please provide an email or a phone number so I can get back to you.

Frequently asked questions

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.

Related pages