Feature request: add standard configuration for nginx on the instructions or README

[GwynethLlewelyn]

Gallery supports Apache, straight out of the box. nginx, however, is another completely different beast. It took me literally years to get it right... namely, to find a 5-year-old working configuration (aye, there are hundreds of solutions out there, most of which too outdated, straight 'conversions' from the Apache rewrite rules (which are ugly and rarely efficient) or even using the dreadful if statement, which is not supposed to be used.

Because it's so hard to get Gallery3 working under nginx, I'd love to request that a working configuration for nginx is added on the installation instructions (or on a separate file). I'd add it to the old Wiki, but, alas, I'm aware that there is no access for the common rabble such as myself... 😉

Anyway, the following solution by @jonmiller works: http://jonamiller.com/2015/02/15/gallery3-on-nginx/

Because the Internet is fickle, and sites come and go (his blog only has two entries from 2015, clearly something he has not been updating...), taking into account that all credits are due to Jon Miller, here is the working configuration:

server {
    server_name <gallery_url>;
    listen 80;

    root <path_to_gallery_installion>;

    access_log <path_to_log_locations>;
    error_log <path_to_log_locations>;

    index index.php;

    location / {

        location ~ /(index\.php/)?(.+)$ {
            try_files $uri /index.php?kohana_uri=$2&$args;
            location ~ /var/thumbs/.*/.album.jpg {
                # Direct access to album thumbs explicity allowed
            }
            location ~ /\.(ht|tpl(\.php?)|sql|inc\.php|db)$ {
                deny all;
            }
            location ~ /var/(uploads|tmp|logs) {
                deny all;
            }
            location ~ /bin {
                deny all;
            }
            location ~ /var/(albums|thumbs|resizes) {
                rewrite ^/var/(albums|thumbs|resizes)/(.*)$ /file_proxy/$2 last;
            }
            location ~* \.(js|css|png|jpg|jpeg|gif|ico|ttf)$ {
                try_files $uri /index.php?kohana_uri=$uri&$args;
                expires 30d;
            }
        }

        location = /index.php {
            include fastcgi_params;
            fastcgi_index index.php;
            fastcgi_split_path_info ^(.+\.php)(.*)$;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_param PATH_INFO $fastcgi_path_info;
            fastcgi_pass localhost:9000; // adjust as necessary
        }
    }
}

But Jon Miller goes further and explains that the real trick that made all the above work correctly was to change one line on application/config/config.php:

$config["index_page"] = "";

Incredibly, this is all it takes, and Gallery 3.1.3 will be fully operational under PHP 7.4 (I'm trying to see the hurdles of activating PHP 8.0, but I'm well aware that Gallery 3.1.3 only works up to 7.4)

[bwdutton]

The docker container I initially created used Nginx until I realized the permissions weren't supported. Gallery currently requires .htaccess files for any content that has permissions enabled and nginx/php-fpm doesn't support that. As a workaround all content could be routed through the /file_proxy/ path although I think this wouldn't be as performant as gallery would be handling all file requests instead of leaving that to the web server: https://github.com/bwdutton/gallery3/blob/master/modules/gallery/controllers/file_proxy.php#L31 I think any fully supported Nginx solution would require some gallery changes on how permissions are handled.

For reference here is the Nginx config I had previously in the docker setup: https://github.com/bwdutton/gallery3-docker/commit/bdf4373d57c19cf52ab7bb5fd52bc3cbfc93d4ea

[GwynethLlewelyn]

Aye, I'm well-aware of the existence of so much PHP software written with the assumption that they can offload all heavy-duty security tasks to simple Apache rewrites on .htaccess files; I've done such changed myself on a few ancient projects, to get them running under nginx... so I know the pain it is.

I guess that the whole permission systems need to be overhauled, then. Since I don't use them (probably because I was used to Gallery 2 that I wasn't even aware that there was such a concept as 'permissions' in Gallery 3), I have been able to use nginx/php-fpm as-is, with the tiny change mentioned earlier.

Delegating permissions to the webserver as opposed to dealing them in the code — beyond the obvious cases — is not really a sustainable, long-term solution. A decade ago, Apache changed considerably how the configuration files were written. What seemed to be 'minor' changes did really affect how certain security/permissions declarations were being interpreted, and we can still find today information about how to convert from the 'old' format to the 'new' (which is not so new...) one.

Interestingly, Gallery seems to be already using an alternate mechanism to .htaccess for some of its configurations, namely, placing PHP configuration changes in a php.ini file (nginx actually tends to use .user.ini for that very purpose ). Such configurations actually work reasonably well, but they're mostly used by Gallery to change specific PHP configuration values and not to deal with permissions. Which is a pity, similar approaches could (?) have been used for permission support as well.

Or, alternatively, all security issues could be handled by a special (to be developed) Gallery module using, say, the ability to prepend a PHP file to all requests — where all the perm(issions magic would be handled...

Oh well, I digress; I really have no idea how the permission system works. All I know is how to convert some .htaccess to the nginx equivalent. And, for inspiration, I can do that conversion manually, using tools such as this one. I'm well aware that such tools are, at best, very crude, requiring a human to go through the output of such a tool and eventually apply whatever changes are deemed nessesarry...

[GwynethLlewelyn]

This message was duplicated from the above one