Creating new user, work, collection etc. fails when using nginx reverse proxy and certbot SSL

[bellisk]

Describe the bug
I've deployed my own Ourchive instance following the steps described here, including setting up SSL using certbot and an nginx reverse proxy. POST requests to the site (e.g. creating a new user or new work) were not successful, even after working around #131. No errors were logged.

After some debugging, this turned out to be because the nginx config from certbot redirects all requests from http://example.org to https://example.org with a 301 response, which browsers generally respond to by transforming the request method to GET.

The problem here is that this seems to be happening all the time. Although I am visiting my Ourchive site with the https:// url, every request is first accepted as an http request and a 301 response is returned. The subsequent request to the https:// url then uses the GET method. This meant that no POST requests were working at all.

I have solved this for now by adjusting the nginx config to redirect with a 308 response code, which doesn't change the request method on redirect. This might be more of an nginx issue (?) but I thought it was worth reporting anyway.

To Reproduce

1. Deploy Ourchive to VPS hosting and set up nginx and SSL as described in https://docs.getourchive.io/admin-getting-started/
2. Try to create a new user or a new work as a logged-in user
3. Creation will fail

Expected behavior
Creating a new user, new work, etc. should succeed.

Desktop (please complete the following information):

• OS: Linux Mint
• Browser: Firefox
• Version: 124

Hosting
Digital Ocean droplet running Ubuntu 22.04.

Additional context
nginx config:

server {
    client_max_body_size 300M;
    server_name example.org;

    location = /favicon.ico { access_log off; log_not_found off; }
    location /static/ {
        root /home/ourchive/ourchive/ourchive_app;
    }
    
    # assumes a media folder at /mnt/ourchive-volume/media
    location /media/ {
        root /home/ourchive;
    }


    location / {
        include proxy_params;
        proxy_pass http://unix:/home/ourchive/ourchive/ourchive_app/ourchive_app.sock;
	add_header X-Robots-Tag "noindex, nofollow";
    }

    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/example.org/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/example.org/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 {
    if ($host = example.org) {
        return 301 https://$host$request_uri;
    } # managed by Certbot


    listen 80;
    server_name example.org;
    return 404; # managed by Certbot
}

Example logs:

urllib3.connectionpool DEBUG 2024-04-19 18:01:54,973 connectionpool 14728 139836487703328 Starting new HTTP connection (1): example.org:80
urllib3.connectionpool DEBUG 2024-04-19 18:01:54,980 connectionpool 14728 139836487703328 http://example.org:80 "POST /api/works/ HTTP/1.1" 301 178
urllib3.connectionpool DEBUG 2024-04-19 18:01:54,981 connectionpool 14728 139836487703328 Starting new HTTPS connection (1): example.org:443
urllib3.connectionpool DEBUG 2024-04-19 18:01:55,074 connectionpool 14728 139836487703328 https://example.org:443 "GET /api/works/ HTTP/1.1" 200 102

[c-e-p]

@bellisk Definitely worth reporting, thank you. I'll check my own nginx config and at minimum we can add some documentation about how best to configure this. Our goal with v1 is to support more guided/low-friction installs which means this kind of config will have to be standardized/documented anyway.