Wrong scheme in download link still not fixed

[andymarden]

#88

Simple use case:

Nginx is reverse proxy - fileshelter is accessed at https://fileshelter.example.com
Nginx does proxy pass through to http://internal-server:5091
Download links created as http://fileshelter.example.com

The way most docker containers deal with all this is to have an EXTERNAL_URL env variable set which would be http://fileshelter.example.com and the code uses this as the link prefix for everything.

Good because it doesn't matter how many proxies yo go through - you are in control.

Can we get that implemented? I may have a go if noone else does.

[epoupon]

Hmmm it should already work.
Have you tried the behind-reverse-proxy + trusted-proxies settings in the file shelter.conf file?
Fileshelter should eventually pick up the original url as seen by the client.

[andymarden]

Aha - I see it is the same as another closed issue - the link is https but the text displayed is http. Surely those two can be constructed from the same data?

I don't know if it is because I am bouncing around nginx and authentik to put auth on the non-download urls. That's why, in addition to fixing this having an optional override may be simplest to guarantee it always works.

I am going to to a for and then pull-request over the next couple of days to remove the Create button from the download page so why don't I pick up this fix and the optional override?

[andymarden]

I can see also that if I go in not through nginx reverse proxy, the displayed link test gets http but there is no prefix on the link itself. Anyway - going in....

[andymarden]

OK - fixed it and creating pull request now.

The cause is a bit ridiculous - in wt4, a wLink object references something (X-Forwarded-Proto probably which is set in the reverse proxy) to embed the correct scheme in the link but the url() method does not contain the scheme and there is no way to get it out. Nice.

So you have to use the environment object - but this does not be default pay attention to X-Forwarded-Proto. There is apparently a way to make it do that but, rather than mess with the build, I felt it was clearer to get the X-Forwarded-Proto scheme explicitly in the code (and default to http if not set).

I'm sure this made sense to someone at some point in the wt4 world but what a song and dance just to get the full URL!

[andymarden]

I don't seem to have permissions to create a Pull Request on the repo - can you enable that?

[epoupon]

You have to fork the project, create a branch (from the develop branch), push commits in that branch and then open a PR between your branch on your fork and the develop branch on the upstream repository

[andymarden]

OK - so permissions are ok. I did a copy to my gitea server and perhaps that's the issue then. OK - let me see.

[andymarden]

Need to ensure it works with no reverse proxy for https too - will fix that

[epoupon]

By the way, I use the exact same settings for the demo instance (nginx handling https, redirecting to a http instance), and it does display 'https' in the link...

[andymarden]

Strange - I guess something somewhere is different. It could be how Wt4 is configured perhaps

[andymarden]

done now - pr updated

[epoupon]

By the way did you see this comment? #88 (comment)
Did you edit the trusted proxy list to add the default one set by the docker setup?

[epoupon]

Maybe you missed it because the doc is still on the develop branch, see https://github.com/epoupon/fileshelter/blob/develop/INSTALL.md#reverse-proxy-settings