Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not working/borked behind a nginx reverse proxy subpath #94

Open
farfalleflickan opened this issue Jan 26, 2024 · 1 comment
Open

Not working/borked behind a nginx reverse proxy subpath #94

farfalleflickan opened this issue Jan 26, 2024 · 1 comment

Comments

@farfalleflickan
Copy link

Here is my nginx setup:

location /files/ {
    proxy_buffering off;
    proxy_buffer_size 4k;
    proxy_read_timeout  120;
    proxy_request_buffering off;
    client_max_body_size 1G; # Make the number the same as 'max-share-size' in fileshelter.conf

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Host $http_host;

    proxy_pass http://127.0.0.1:8003/;
}

With this in nginx and fileshelter's deploy-path set to the default /, everything works fine BUT the download link is wrong and points to the root of the domain (do note that if I manually add the files subpath to the download link, it all works fine).

But if I do set deploy-path to files, then nothing works at all and in the browser console I see a bunch of MIME type errors as I have nginx configured with X-Content-Type-Options: nosniff. If I turn this off then I get loading errors like Fatal error: failed loading /files/resources/themes/bootstrap/5/bootstrap.bundle.min.js

Basically, i am in a catch 22, if I set deploy-path to my subpath it is entirely fucked, if I don't only the download button is fucked. Looks to me as if deploy-path is also impacting the resources path, so maybe it is used internally by Wt?

@farfalleflickan
Copy link
Author

farfalleflickan commented Mar 5, 2024

Re-looking, at the code and comparing ShareUtils.cpp (whose links are correct, they contain the subpath) with ShareResource.cpp (which does not...)

maybe ShareResource.cpp:createLink

return {Wt::LinkType::Url, std::string {getDeployPath()} + "?id=" + uuid.toString() + (password ? ("&p=" + Wt::Utils::hexEncode(std::string {*password})) : "")};`

should be

return {Wt::LinkType::Url, wApp->environment().urlScheme() + "://" + wApp->environment().hostName() + (wApp->environment().deploymentPath() == "/" ? "" : wApp->environment().deploymentPath()) + "?id=" + uuid.toString() + (password ? ("&p=" + Wt::Utils::hexEncode(std::string {*password})) : "")};

Which is basically a mashup of ShareResource.cpp and ShareUtils.cpp.
I wasn't able to get libwt running on my Debian setup so I unfortunately cannot test this myself....

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant