Self-hosted setup limiting CORS origin breaks Ente web

[woodedjurassicpark]

Issue

I have a single server setup with an nginx reverse proxy. I am using a Garage S3 server on the same server. I can successfully use Ente web if my S3 Allow-Origin header is set to '*'. However, if I set the Allow-Origin to anything else, then XHR GET requests break when using using Ente web from any browser. The Allow-Origin header gets set to null when GET requests are sent to S3. Therefore, images don't load but uploads work.

There is some discussion on Discord here https://discord.com/channels/948937918347608085/1455243698794139901

Troubleshooting

I setup a custom log to see that the origin is being mapped correctly, when the browsers request origin is not null.

Configuration

io.example.net (NGINX - Garage - S3 )

# Map allowed CORS origins
map $http_origin $cors_origin {
    default "";
    "https://photos.example.net" $http_origin;
    "https://api.example.net" $http_origin;
    "https://albums.example.net" $http_origin;
    "http://127.0.0.1:3000" $http_origin;
}

log_format custom '$cors_origin - $http_origin';

server {

    server_name io.example.net;

    client_max_body_size 0;

    access_log /var/log/nginx/io.access.log;
    access_log /var/log/nginx/io.access.custom.log custom;
    error_log /var/log/nginx/io.error.log;

    location / {
        proxy_pass http://127.0.0.1:3900;
        include proxy_params;

        proxy_max_temp_file_size 0;

        # Enable CORS
        add_header 'Access-Control-Allow-Origin' $cors_origin;
        add_header 'Access-Control-Allow-Headers' '*';
        add_header 'Access-Control-Allow-Methods' 'GET, HEAD, POST, PUT, DELETE';
        add_header 'Access-Control-Max-Age' '3000';
        add_header 'Access-Control-Expose-Headers' 'Etag';

        # Handle preflight OPTIONS request
        if ($request_method = OPTIONS) {
            add_header 'Access-Control-Allow-Origin' $cors_origin;
            add_header 'Access-Control-Allow-Headers' '*';
            add_header 'Access-Control-Allow-Methods' 'GET, HEAD, POST, PUT, DELETE';
            add_header 'Access-Control-Max-Age' '3000';
            return 204;  # No content response
        }
    }

    listen [::]:20006 ssl; # managed by Certbot
    listen 20006 ssl; # managed by Certbot
    http2 on;
    ssl_certificate /etc/letsencrypt/live/io.example.net/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/io.example.net/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

}

[adsche]

Hi, have you had any luck resolving this?

I'm facing the same issue, but only from ente web. Apps seem to work fine.

Is self-hosted ente web working for anyone without Allow-Origin '*'? There's quite a bit of info on when the browser sends Origin: null on SE but from that, I don't really see a way to get around this issue purely by configuration - it seems the web app would need to change...?

I tried reading the discord thread, but the link leads me to an empty page. I then tried to join the ente community discord (maybe I have to do that first?) but there was an unskippable question about receiving notifications without the possibility of selecting "none", so I don't really want to do that... :/

[woodedjurassicpark]

I have not resolved this, from my perspective it seems the ente web code would need to be fixed.

There’s a less than ideal workaround by using IP based access in the reverse proxy config. This would work in my scenario, as I use nginx and only the ente services would be touching my Garage S3 server.

[adsche]

Ahh yeah that's a sensible workaround, thanks! That would work in my case as well.

[ssddanbrown]

I also ran into this scenario.

From what I could tell, this is due to the S3 request coming from a redirect provided by the Ente API. Since this is a cross-origin redirect, this causes the browser to set a null/opaque origin, which then fails non-wildcard CORS checks.

My solution to this was a tad hacky: I configured my S3 system (garage) to be on the same origin as the Ente api (managed via caddy at reverse-proxy level). I could not find a way to put garage on a specific sub-path, since this messed with signatures used, but since all requests appear to use the bucket name in the path, I created a relatively unique bucket name (s3ente) then proxied all /s3ente requests to the API to go to garage instead.
This results in the redirects being same-origin, and therefore they contain the origin to pass CORS checks.
Still testing this setup out but basic image uploading/viewing is now working with this.

[ssddanbrown]

An update to this: It seemed to cause problems with the desktop applications (worked fine on web and mobile).
Had to resort to wildcard origin CORS to get thumbnails showing in the desktop app.