Score:1

NGINX getting an application in a subfolder to work with redirects

cn flag

I've installed Mautic in a subfolder like: example.com/m
Most of Mautic is working fine with my configuration (admin panel, using Mautic etc.) but for some redirects in my subfolder, I get a 404:

example.com/m 200
example.com/m/form/9 200
example.com/m/form/generate.js?id=9 404

(/form doesn't exist - it should be redirected/generated by Mautic dynamically)

All files on the file system belong to www-data.

My nginx conf for the host:

server {
    server_name www.example.com;
    rewrite_log on;

    root /var/www/example.com/www.example.com;
    index index.php index.html index.htm;

    access_log /var/log/nginx/example.com_access.log;
    error_log /var/log/nginx/example.com_error.log notice;

    #######################################
    ##  Start Mautic Specific config #####
    #######################################

    location /m {
        # Working despite forms:
        try_files $uri $uri/ /m/?q=$uri&$args;
    }

    #######################################
    ##  End Mautic Specific config #####
    #######################################

    location / {
        try_files $uri $uri/ /index.php$is_args$args;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php7.3-fpm.sock;
    }

    # A long browser cache lifetime can speed up repeat visits to your page
    location ~* \.(jpg|jpeg|gif|png|webp|svg|woff|woff2|ttf|css|js|ico|xml)$ {
       access_log        off;
       log_not_found     off;
       expires           360d;
    }

    # disable access to hidden files
    location ~ /\.ht {
      access_log off;
      log_not_found off;
      deny all;
    }

    listen [::]:443 ssl; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/stats.example.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/stats.example.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

server {
    listen 443 ssl;
    server_name example.com;
    listen [::]:443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/stats.example.com/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/stats.example.com/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
    return 301 https://www.example.com$request_uri;

}

server {
    if ($host = example.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    if ($host = www.example.com) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    server_name example.com www.example.com;
    listen 80;
    listen [::]:80;
    return 301 https://$host$request_uri;
    #return 404; # managed by Certbot

}

What am I doing wrong?

Richard Smith avatar
jp flag
Your `location ~* \.(jpg|jpeg|gif|png|webp|svg|woff|woff2|ttf|css|js|ico|xml)$` block is handling the URI that ends with `.js`. You could try moving that block inside the `location /` block.
cn flag
That's correct indeed. It's working now. If you add it as an answer, I'll accept it :)
Score:1
jp flag

You want URIs that begin with /m to be handled by the location /m block.

However, regular expression locations take precedence, so the URI /m/form/generate.js is actually being handled by another location that matches all URIs that end with .js. See this document.

There is the ^~ operator which forces the prefix location to take precedence, but that will not work in your case, as the application is PHP, and you need URIs that end with .php to be handled by the location ~ \.php$ block.

So instead, I suggest you nest the location causing the problem within the location / block.

For example:

location /m {
    try_files $uri $uri/ /m/?q=$uri&$args;
}

location / {
    try_files $uri $uri/ /index.php$is_args$args;

    location ~* \.(jpg|jpeg|gif|png|webp|svg|woff|woff2|ttf|css|js|ico|xml)$ {
        access_log        off;
        log_not_found     off;
        expires           360d;
    }
}

location ~ \.php$ {
    ...
}

location ~ /\.ht {
    ...
}
cn flag
Thanks, very understandable!
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.