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)