Search seems to cause errors in Firefox

[gBasil]

When I search for a track, Maloja sends a request to https://<domain>/api/search?max=5&query=a It returns a 308 to http://<domain>/apis/mlj_1/search?max=5&query=a And that returns a 301 to https://<domain>/apis/mlj_1/search?max=5&query=a And that request finally returns the search data. On Firefox, this ends up causing the request to not go through:

I'm not sure if this is an error with my configuration (Maloja running on NixOS behind Cloudflare, accessed via Firefox) or if it's to do with Maloja redirecting to HTTP instead of HTTPS.

[gBasil]

This issue also appears when using the upload image feature, so it's probably an issue with my configuration, though I'm not sure how to fix it or what's causing it.

[Velocidensity]

Are you running maloja behind nginx? If so, you should set X-Forwarded-Proto to "https", otherwise maloja/bottle (the web server) has no way of knowing the user is using https. This bit of code in the proxy section does the trick:

proxy_set_header X-Forwarded-Proto https;

Removing the redirects might be worthwhile (and has happened before, in #51), as there is no reason for the JS to have deprecated endpoints hardcoded (images, search, and rule toggling are two places I ran into this too).

On that note, I noticed maintainer's own server has a redirect loop issue on the images endpoint. https://maloja.krateng.ch/image?album_id=16

[gBasil]

That seems to have done the trick, thank you!

[ThinkChaos]

I have the headers properly setup (confirmed by dumping them) but still have issues with plaintext redirects. After looking into it, I'm pretty sure bottlepy/bottle/pull/747 would fix it but not fix the actual root cause. The root cause is the HTTPS scheme info being lost, but I'm not sure how that happens.

I'm now using a workaround on the reverse proxy side. In Nginx http block:

map $upstream_http_location $same_scheme_location {
  '~^http://(.+)' '//$1';
  default         $upstream_http_location;
}

In server or location block:

proxy_hide_header location;
add_header location $same_scheme_location;

[gBasil]

This issue started happening to me again as well, actually, but you seem to have actually diagnosed it (I just added a modified version of the search script as a userscript :P).

@ThinkChaos Should I reopen this issue?

[ThinkChaos]

Yeah I'd reopen it if it's also an issue for you. At least it'll make it easier for others to find this!