Getting 302 ERR_TOO_MANY_REDIRECTS

[YPCrumble]

I'm getting the 302 error ERR_TOO_MANY_REDIRECTS on my Revive Adserver installation. It sounds similar to this GitHub issue: https://github.com/revive-adserver/revive-adserver/issues/151

curl $domain/www/admin/install.php returns nothing. 

The issue isn't with my NGINX installation. I'm pasting it below, but the thing is that if I change `index index.php` to `index index.html` and add a simple html file at /var/www/html/index.html then that file serves fine. It seems that for some reason the PHP code has created an infinite redirect loop when `index index.php` calls that file in my build.

I have tried clearing my cookies/browser cache/session data and completely starting from scratch with a fresh build without success.

Any suggestions on what might be the issue and how I could debug? Thank you for any help! Please let me know if there's any further information I might provide.

nginx.conf: 

 

```

user www-data;
worker_processes 2;
error_log       /var/log/nginx/error.log error;
pid             /var/run/nginx.pid;

events {
    worker_connections 1024;
}

http {
    include mime.types;
    default_type application/octet-stream;
    sendfile on;
    keepalive_timeout 65;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';
    server {
        listen 80;
        server_name localhost;

        client_max_body_size 4M;
        client_body_buffer_size 128k;
        access_log /var/log/nginx/localhost.access.log;
        error_log /var/log/nginx/localhost.error.log;

        root /var/www/html;
        index index.php;

        location ~ \.php$ {
            try_files $uri =404;
            include fastcgi_params;
            fastcgi_param   SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_pass unix:/var/run/php5-fpm.sock;
        }
    }
}

```

Edited December 15, 2017 by YPCrumble

[Matteo Beccati]

Sorry, that's very little information for us to help.

• Is this a brand new install?
• Are you trying to install it right now?
• Do you have a config file for the domain you're using?
• Anything in the nginx or fpm log files?
• Anything in Revive's own var/debug.log?

[YPCrumble]

Thanks for your answer! Yes, this is a brand new install, and yes I'm trying to install it right now. I'm installing it on my own localhost - I should be able to visit localhost:8080.

Nothing in the fpm log files. Copying that here just in case:

[15-Dec-2017 17:04:03] NOTICE: fpm is running, pid 21
[15-Dec-2017 17:04:03] NOTICE: ready to handle connections
[15-Dec-2017 17:04:03] NOTICE: systemd monitor interval set to 10000ms

I have searched the entire directory structure of the site and can't see any debug.log file. Where might that reside? Though I think it's just not appearing because it doesn't exist yet. 

The only thing in the nginx log file is redirects from /www/admin/index.php to /www/admin/install.php and back again. It appears to be the same as this issue: 

 

[Matteo Beccati]

Nginx is listening on port 80, yet you talk about 8080.

[YPCrumble]

Yes - this is because I'm using Docker. The PORT setting for Docker is simply 443/tcp, 0.0.0.0:8080->80/tcp

I don't think it's a Docker issue however, because NGINX works fine - like I said if I replace the `index index.php` directive with a simple static index.html file, it gets served no problem at localhost:8080 on my machine. 

[YPCrumble]

I figured out the issue. I'm not 100% sure the cause, but I had to completely rebuild my MySQL server and it worked fine. Previously I had just just been rebuilding my Revive server. Perhaps there was a redirect issue due to a cached response from the MySQL server?

Matteo, in any case thank you for your help! 

[YPCrumble]

UPDATE: the issue was my permissions on my revive-adserver folder. I was installing them with 644 permissions rather than 700 into `/var/www/html`. By changing back permissions to 700 the redirect stopped. Hopefully this helps someone in the future.

@Matteo do you happen to understand why the improper permissions might have caused this redirect, or which code is likely the source of the redirect? I'd love to submit a PR that causes Revive to fail loudly in the event that permissions are improperly set on its source files. That would have made this redirect issue much easier to debug.