Caddy with Prestashop - rewrite rules


(Giuseppe M.) #1

Hello,

I’m trying to use PrestaShop 1.7.5.1 with Caddy, the installation of the e-commerce platform went fine, but when I attempt to access the domain, the browser returns ERR_TOO_MANY_REDIRECTS (with Chrome, I get a similar message with Mozilla Firefox).

The access log looks like this:

requested_from - - [06/Apr/2019:14:01:01 +0000] "GET / HTTP/2.0" 302 23
requested_from - - [06/Apr/2019:14:01:01 +0000] "GET /index.php HTTP/2.0" 302 23
requested_from - - [06/Apr/2019:14:01:01 +0000] "GET /index.php HTTP/2.0" 302 23
requested_from - - [06/Apr/2019:14:01:01 +0000] "GET /index.php HTTP/2.0" 302 23
requested_from - - [06/Apr/2019:14:01:01 +0000] "GET /index.php HTTP/2.0" 302 23
requested_from - - [06/Apr/2019:14:01:01 +0000] "GET /index.php HTTP/2.0" 302 23
requested_from - - [06/Apr/2019:14:01:01 +0000] "GET /index.php HTTP/2.0" 302 23
requested_from - - [06/Apr/2019:14:01:01 +0000] "GET /index.php HTTP/2.0" 302 23
requested_from - - [06/Apr/2019:14:01:01 +0000] "GET /index.php HTTP/2.0" 302 23
requested_from - - [06/Apr/2019:14:01:01 +0000] "GET /index.php HTTP/2.0" 302 23
requested_from - - [06/Apr/2019:14:01:01 +0000] "GET /index.php HTTP/2.0" 302 23

I’m using a VPS Ubuntu 18.04 with a compiled from source Caddy, version 0.10.3. And I’m using a subdomain which is configured like this:

sub.domain.tld {
    root /path/public
    gzip
    tls email@domain.tld
    timeouts 10m

    fastcgi / /path/php-fpm.sock php {
        read_timeout    1800s
        send_timeout    1800s
        connect_timeout 20s
    }

    header / {
        # Enable HTTP Strict Transport Security (HSTS) to force clients to always
        # connect via HTTPS (do not use if only testing)
        Strict-Transport-Security "max-age=31536000;"
        # Enable cross-site filter (XSS) and tell browser to block detected attacks
        X-XSS-Protection "1; mode=block"
        # Prevent some browsers from MIME-sniffing a response away from the declared Context
        X-Content-Type-Options "nosniff"
        # Disallow the site to be rendered within a frame (clickjacking protection)
        X-Frame-Options "SAMEORIGIN"
        # Removing Server header
        -Server
        # Control frame ancestors
        Content-Security-Policy "
                default-src 'self';
                frame-ancestors 'none'
        "
    }

    log /path/logs/sub_domain_access.log {
        rotate_size 25 # Rotate after 25 MB
        rotate_age  30 # Keep rotated files for 30 days
        rotate_keep 10 # Keep at most 10 log files
    }
}

I see from the Prestashop .htaccess rewrite rule that the relevant rule is:

    RewriteRule . - [E=REWRITEBASE:/]

Which should be:

    rewrite {
        r (.*)
        to {path} {path}/ /index.php?{uri}
    }

I’ve tested the above rewrite rule, but I had no success. And even by removing the rule and reloading the server, I get the same redirect error.

How can I solve?

Thank you.


(Matthew Fay) #2

Hi @cereal, welcome to the Caddy community!

For context, what’s the looped redirect, exactly? What Location header do you get?


(Toby Allen) #3

Try using {rewrite_uri} in your log to see what each request is being redirected to

log / d:\logfile.txt "{common} {rewrite_uri}" {
etc...

(Giuseppe M.) #4

Hello!

@Whitestrake here is the full request and response, the response location seems to point to http://

Request URL
https://domain.tld/

Request Headers
Host: domain.tld
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:66.0) Gecko/20100101 Firefox/66.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Pragma: no-cache
Cache-Control: no-cache
TE: Trailers

Response Headers
HTTP/2.0 302 Found
cache-control: no-cache
content-encoding: gzip
content-type: text/html; charset=utf-8
location: http://domain.tld/index.php
status: 302 Moved
strict-transport-security: max-age=31536000;
vary: Accept-Encoding
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
content-length: 23
date: Sun, 07 Apr 2019 08:57:00 GMT
X-Firefox-Spdy: h2

These are repeated until the browser stops it. An extra header that I get while using Chrome has status 307 Internal Redirect, it looks like this:

Request
Request URL: http://domain.tld/

Response:
HTTP/1.1 307 Internal Redirect
Location: https://domain.tld/
Non-Authoritative-Reason: HSTS

It seems it is switching from http to https and then back to http with a 302. This does not happen in the login interface for the admin panel, nor it happens in the dashboard, but I still cannot access all the other pages. To be honest I’m starting to think it’s not the server but the Prestashop code.

@tobya here’s the resulting log:

requested_from - - [07/Apr/2019:08:49:08 +0000] "GET /index.php HTTP/2.0" 302 23 /index.php
requested_from - - [07/Apr/2019:08:49:08 +0000] "GET /index.php HTTP/2.0" 302 23 /index.php
requested_from - - [07/Apr/2019:08:49:08 +0000] "GET /index.php HTTP/2.0" 302 23 /index.php
requested_from - - [07/Apr/2019:08:49:08 +0000] "GET /index.php HTTP/2.0" 302 23 /index.php
requested_from - - [07/Apr/2019:08:49:08 +0000] "GET /index.php HTTP/2.0" 302 23 /index.php
requested_from - - [07/Apr/2019:08:49:08 +0000] "GET /index.php HTTP/2.0" 302 23 /index.php
requested_from - - [07/Apr/2019:08:49:08 +0000] "GET /index.php HTTP/2.0" 302 23 /index.php
requested_from - - [07/Apr/2019:08:49:08 +0000] "GET /index.php HTTP/2.0" 302 23 /index.php
requested_from - - [07/Apr/2019:08:49:08 +0000] "GET /index.php HTTP/2.0" 302 23 /index.php
requested_from - - [07/Apr/2019:08:49:08 +0000] "GET /index.php HTTP/2.0" 302 23 /index.php

While with {combined} I get the same but with the browser user agent:

requested_from - - [07/Apr/2019:08:50:58 +0000] "GET /index.php HTTP/2.0" 302 23 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36" /index.php

Thanks for your replies :slight_smile:


(Matthew Fay) #5

Given your Caddyfile, Caddy will only be issuing one redirect - from HTTP to HTTPS (setup by default by the Automatic HTTPS feature).

I’d have to assume that PrestaShop is issuing redirects to HTTP, then - see if you can find a HTTPS or Scheme or site URL option that you can instruct it to accept HTTPS requests.

As for this:

Chrome here is respecting your strict-transport-security: max-age=31536000; header and issuing its own 307 to itself to go straight to HTTPS.


(Giuseppe M.) #6

Okay, thank you for the suggestion, it helped me: I was able to access the application by expliciting the protocols in the Caddy vhosts file:

http://domain.tld/ {
	...
}

https://domain.tld/ {
	...
}

Then I accessed the HSTS of the browser:

chrome://net-internals/#hsts

And deleted the entry for the domain. This allowed me to skip the redirect loop. Now I have to deal with the rewrite rules, but I’ll address eventual questions to a new thread.

This, from my point of view, can be considered solved.

Thank you :slight_smile: