Error 302: ERR_TOO_MANY_REDIRECTS in Back Office

[mtdkuser]

Hello,

I would like to set up a local Docker-based development environment for theme and plugin development. The environment would be a copy of the existing store, however, I have encountered an issue.
Despite completing the migration steps and adjusting the configuration settings, I cannot log into PrestaShop Back Office (BO). After migrating the database and setting the store's URLs in the appropriate tables in the database, the store seems to work locally at first sight. However, I can't log into the admin panel because when I try to access the Back Office (from the URL I defined in the PS_FOLDER_ADMIN environment variable in docker-compose.yaml), the site falls into redirect loop (error 302 - ERR_TOO_MANY_REDIRECTS).
Has anyone of you encountered this issue before and is able to help me solve it?

Here's what I've done so far:

- I downloaded a database dump of the existing store.
- I configured docker-compose and set up a clean store locally.
- I imported the downloaded database dump.
- I updated the appropriate values in the PS_CONFIGURATION and PS_SHOP_URL tables.
- I deleted the cache files and even tried deleting the .htaccess file.

Additional information:
- Prestashop version: 8.1.4
- MySQL version: 5.7

The problem persists in different browsers, which rules out a cookie issue.
Thank you in advance for your help!

[Paul C]

I usually mount the database and /var/www/html directories locally, did you do that?

If it helps this is the format I use for a staging site (copy of production site). I also use nginxproxymanager in a docker container (to send domain requests to the correct IP and port) and then use Cloudflare to set up DNS records that point to my server for each instance I'm running.

 

version: "3"

services:
  staging-mysql:
    container_name: staging-mysql
    
    image: mariadb:<prod-db-ver>
    
    volumes:
      - /my/home/directory/ps-staging/db:/var/lib/mysql
      - /my/home/directory/ps-staging/database-import:/docker-entrypoint-initdb.d
    
    environment:
      MYSQL_ROOT_PASSWORD: 'very-secure-password'
      MYSQL_DATABASE: 'mydbname'
      MYSQL_USER: 'mydbuser'
      MYSQL_PASSWORD: 'mydbusers-pw'
    
    restart: unless-stopped
    
    networks:
      - prestashop-staging

  ps-staging:
    container_name: ps-staging
    image: prestashop/prestashop:<prod-ps-ver+php-ver>
    
    ports:
      - "8080:80"
    
    depends_on:
      - staging-mysql
    
    volumes:
      - /my/home/directory/ps-staging/src:/var/www/html

    environment:
      DB_SERVER: 'staging-mysql'
      DB_NAME: 'mydbname'
      DB_USER: 'mydbuser'
      DB_PASSWD: 'mydbusers-pw'
      DB_PREFIX: 'xx_'
      PS_DEV_MODE: '0'
      PS_HOST_MODE: '0'
      PS_DEMO_MODE: '0'
      PS_INSTALL_AUTO: '0'
      PS_ERASE_DB: '0'
      PS_INSTALL_DB: '0'
      PS_LANGUAGE: 'en'
      PS_COUNTRY: 'GB'
      PS_ALL_LANGUAGES: '0'
      PS_FOLDER_ADMIN: 'admin'
      PS_FOLDER_INSTALL: 'install'
      PS_ENABLE_SSL: '1'
      ADMIN_EMAIL: '[email protected]'
      ADMIN_PASSWD: 'my_admin_pw'
      PS_HANDLE_DYNAMIC_DOMAIN: '1'

    restart: unless-stopped

    networks:
      - prestashop-staging

  phpmyadmin:
    container_name: phpmyadmin
    image: phpmyadmin/phpmyadmin
    ports:
      - 1237:80
    depends_on:
      - staging-mysql
    links:
      - staging-mysql
    environment:
      PMA_HOST: 'staging-mysql'
      PMA_PORT: '3306'
      PMA_ARBITRARY: '1'

    restart: unless-stopped

    networks:
      - prestashop-staging
    

networks:
  prestashop-staging:
    driver: bridge

To be honest I don't really care about most of the prestashop settings as I drop the production database export into the database-import directory and when you first spin it up it will import your production database automatically. You can then log in to phpmyadmin to change the url. Then copy your production files over (in the the src directory) and you should have a copy of the production site. If you keep all the database names, users and passwords the same as on the production site, then there's very little you need to change.

There might be more than one .htaccess, of course (i.e. in the site root and in the "admin" folder).

EDIT 2: delete the cache manually e.g. *sudo rm -r dev prod* in the var/cache directory if you've copied over files from your source site, of course. 

Edited March 26 by Paul C
changed "local" to "production".... (see edit history)

[Paul C]

Actually another thought occurred to me. Do you have SSL enabled on the site you pulled the database from but not configured for your test site? That would cause similar issues.

PS_SSL_ENABLED and PS_SSL_ENABLED_EVERYWHERE should probably both be 0 if you're not using SSL.

[mtdkuser]

Thank you @Paul C for your reply.

 

What I want to achieve is to configure the environment in a way that the only files mounted in my docker-compose will be the actual files around which the theme/plugin development will be focused.

I don't want to copy all my store files, because I want to be able to quickly recreate the production environment locally on multiple devices but without having to store all the Prestashop store files in my repository.

The production environment on which the store is running is simply Prestashop installed on a virtual machine. The store has installed several plugins (including custom plugins created by us) and a custom theme, which are versioned in the repository. So I thought that for the purpose of further development of the store (on a local environment), the most optimal solution would be to set up Prestashope environment locally with Docker, migrate the database and mount all plugins and the theme in docker-compose. But then we faced the problem I described before.

 

Quote

I usually mount the database and /var/www/html directories locally, did you do that?

No, I haven't done that, but thank you very much for sharing your docker-compose configuration. I'll try to look into it later.

 

Quote

Actually another thought occurred to me. Do you have SSL enabled on the site you pulled the database from but not configured for your test site? That would cause similar issues.

PS_SSL_ENABLED and PS_SSL_ENABLED_EVERYWHERE should probably both be 0 if you're not using SSL.

I had SSL enabled on the production site and of course after the database migration, in addition to changing the site URLs in the database, I also changed the values of PS_SSL_ENABLED and PS_SSL_ENABLED_EVERYWHERE to 0 in PS_CONFIGURATION table. I also tried deleting .htaccess files and cache manually.

[Paul C]

9 hours ago, mtdkuser said:

What I want to achieve is to configure the environment in a way that the only files mounted in my docker-compose will be the actual files around which the theme/plugin development will be focused.

Totally valid and reasonable. The beauty of docker is that you could test your modules/themes with different versions. I do find though that I prefer to exactly match the production site on a staging site (including database version, php version/type and server), even though in theory all the core files should be identical, when working on a single particular site. There are often glitches when say using litespeed on a production server and apache2 on a development site or even just fastcgi vs fpm etc. etc. so it's rare to have a one size fits all scenario! It depends on how "custom" your modules and themes are.

Did the store work fine before you imported the database (assuming that you've installed a vanilla copy of 8.1.4 to start and then uploaded the database)? Also which prestashop image are you using? It might be worth just changing the image e.g. from prestashop/prestashop:8.1.4-8.1-fpm to prestashop/prestashop:8.1.4-8.1-apache in your docker-compose file and then restarting (i.e. docker-compose up -d if you're running detached in a terminal). If you've eliminated .htaccess and ssl then it likely comes down to server configuration. Might be worth logging in to the prestashop image on your virtual machine and checking the vhost settings are correct.

I run docker on ubuntu server as a separate machine and then connect to it from my workstation with the remote extension for VSCode (plus the extensions for github, docker etc.). Works really well although you need to be careful with file permissions, owners etc.

EDIT: Actually it might be worth checking the app/config directory and doing a diff with production. Another reason for redirects can be the language/locale settings but kind of clutching at straws with that.

Edited March 28 by Paul C (see edit history)

[mtdkuser]

Hi @Paul C,

Sorry for the late reply but I had a holiday.

Well, the strangest thing in all of this is that before importing the database, the whole store works fine - even when I have mounted theme/plugin files I want to work on.
Just after importing the dump of the production database, backoffice becomes inaccessible. The moment I go back to the previous database (the clean one, backed up right after installation), everything goes back to normal.

For me, it looks quite like somewhere in the database there are stored values that do not match the values in the store's configuration files (?). Meanwhile, I tried to paste all the configuration files in the app/config directory from the production store to my local store - unfortunately, it didn't change anything.

The image I use is: prestashop/prestashop:8.1.4-apache
Of course, I tried using other images - it doesn't change anything at all.

 

By the way, I noticed that you responded to my GitHub and StackOverflow threads, but I guess it doesn't make sense to have a parallel discussion about this problem on multiple platforms.

 

EDIT:

I noticed that when I try to access the admin panel on the local environment in the store with a "faulty" database, the CSRF token that appears in the URL is always the same as the token that is generated for me when I get to the backoffice in the production store - maybe the CSRF token is somehow related to my problem?

 

EDIT2:

I've also just noticed that when I manually delete the cache files from the var/cache/prod directory, I get a 404 error (Requested URL not found on this server) everywhere on my local site (even on the home page), except for the admin panel, of course - there's a 302 redirect error. The cache files in var/cache/prod are not being regenerated, but when I go back to a clean database, the store works again and the cache files are successfully regenerated.

 

EDIT3:

I decided to download all my store files and mount them in my docker-compose. Unfortunately, the store even in this way cannot be run locally... I am getting a "Unable to persist data in cache data layer" error. Of course, I also uploaded a dump of the production database (with reconfigured URLs) and deleted the contents of the /var/cache directory...

I'm wondering if this is some kind of WSL2 configuration issue (file permissions?) that I'm running docker on.

Edited April 10 by mtdkuser (see edit history)

[mtdkuser]

I almost gave up, but finally managed to find a solution to my problem....
During desperate attempts to "transplant" individual database tables from a clean store database to my imported database (which comes from a production environment), I found that rewriting the "ps_tab" table restores the possibility to get to backoffice eliminating the problem of redirect loops.

Honestly, I have no idea what exactly the problem is (inconsistency of data structure in the tables between my production PrestaShop instance and the local Docker instance?), but I don't even have the strength to analyze it anymore.
I hope this topic will help someone struggling with a similar problem someday.

@Paul C - thank you very much for your help and your commitment.

[Paul C]

@mtdkuser you're welcome. Sorry I couldn't help get you there quicker but I'm not sure I could have replicated it anyway!

[ZHSoft]

Why must you use Docker? How did you get work done in the era without Docker?
I suggest you change your working mindset:

1. Files: Use Git version control to control files and restore them at any time.
2. Database: Back up the database. After completing the test work, delete the existing database and restore the database again.

Based on the above, your work can be completed perfectly without being too complicated or introducing uncontrollable factors.

[Paul C]

23 minutes ago, ZHSoft said:

Why must you use Docker? How did you get work done in the era without Docker?
I suggest you change your working mindset:

1. Files: Use Git version control to control files and restore them at any time.
2. Database: Back up the database. After completing the test work, delete the existing database and restore the database again.

Based on the above, your work can be completed perfectly without being too complicated or introducing uncontrollable factors.

Docker itself isn't complicated - the exact opposite. I can have an exact replica of a customer's production server with the same OS version, PHP version and database version spun up in minutes. Alternatively I can use the PrestaShop supplied images and have a known-good server up and running even quicker, for any version of PrestaShop I need (including server technology and subsystem versions). The problem encountered here was 100% down to data integrity and nothing to do with docker - the same problem would have existed using an outdated server build

1. You can use Git with docker and manage versions with ease.
2. You can make multiple backups of the database easily by taking down the instance, copying the persistent db data folder and then bringing the instance up again. Restoring to a known good point takes minutes. Much faster than an import/export regardless of the database size with no upload file limits etc. to worry about.
3. It can scale easily for multi-server setups.
4. It can be replicated exactly with ease on any machine you need it to be, or as per (3) - multiple instances, all exactly the same.
5. I can test modules and themes across multiple PHP and PrestaShop versions just by changing a couple of lines in the docker config file, or automate it. 

With docker everything is controlled and the majority of the complication of setting up a development environment are removed. You should try it. I certainly wouldn't want to go back to using the tools I used when I started with PrestaShop pre version 1.0.0 .....

[ZHSoft]

Docker is indeed great. I have used Docker for 5 years.
But Docker for most people:
1. Raising the technical threshold
2. Added PrestaShop's Docker file maintenance, introducing uncertainty.

Their energy should be on sales promotion, not technical research.

[Paul C]

@ZHSoft The OP was setting it up for theme and module development though.

Even if he IS a store owner, given the garbage that I've seen that customers have bought from the addon store I would fully support a diy approach - assuming you have the necessary programming skills.

There are great developers and modules on the addon store (I've come across the work of a good few), but the poor quality ones put people off to be honest.

The summary of this thread is that his use of docker was a red herring (which is why it wasn't repeatable). The problem was with the data he imported.

[mtdkuser]

1 hour ago, ZHSoft said:

Why must you use Docker? How did you get work done in the era without Docker?
I suggest you change your working mindset:

1. Files: Use Git version control to control files and restore them at any time.
2. Database: Back up the database. After completing the test work, delete the existing database and restore the database again.

Based on the above, your work can be completed perfectly without being too complicated or introducing uncontrollable factors.

@ZHSoft

Why should I not use it? I use the Docker environment in this project only for the development of the theme and plug-ins for PrestaShop, the store is set up in the traditional way directly on the server. In the past I used a XAMPP-based environment for these purposes, but it was very problematic, Docker has made my work incredibly smooth (due to, among other things, those advantages of Docker that @Paul C mentioned), so that's why I use it.

In general, it turned out that the problem was probably not related to the fact that I am using Docker, here is a quote from another developer who had a similar problem, to my topic about this issue on GitHub:

Quote

Modules like ps_accounts adds it's own route to their own admin login controller, and if a merchant uninstall and deletes this module the route is not deleted (...) and is never found, that's why we get ERR_TOO_MANY_REDIRECTS.

PrestaShop could check if the module is installed before trying to use a nonexistent controller.

(...)

Just tested on my end and the ps_accounts tabs are deleted after module is uninstalled, strange things happens some times on merchants sites.

And at your end you just added them when dumping the DB and maybe the module was not installed at all so it's obvious why it fails.

And perhaps this is what happened in my case, some module wasn't installed, or maybe didn't even exist at all in the PrestaShop Docker image I used on the local environment, but by doing a database dump from production store and importing it into the local environment I also dumped the ps_tab table according to which this module exists/is installed, making AdminController induce a redirection loop. 

The solution to this error seems simple - PrestaShop should check if the modules are present before forcing to use a nonexistent controller.

 

 

1 hour ago, ZHSoft said:

Docker is indeed great. I have used Docker for 5 years.
But Docker for most people:
1. Raising the technical threshold
2. Added PrestaShop's Docker file maintenance, introducing uncertainty.

Their energy should be on sales promotion, not technical research.

I think you should not worry about my business approach to the project, the topic is about a little bug that is quite specific but real and occurs as we see in PrestaShop.