Add custom theme support for qBittorrent

[adepssimius]

---

• [x] I have read the contributing guideline and understand that I have made the correct modifications

---

Description

Add sections to qBittorrent configurations to route requests to /css

Benefits of this PR and context

I was unable to load css assets when using a custom qBittorrent webUI. I saw that my requests to qbittorrent.*/css/... were being redirected to authelia. This change routes traffic to the correct container instead of redirecting.

How Has This Been Tested?

I made the edits to the subdomain configuration in my existing swag/Bbittorrent stack and saw that the css requests were no longer being incorrectly redirected and that the custom styles were correctly applied. I unapplied the custom style through the qBittorrent options menu, restarted the qBittorrent container and saw that the original theme was not affected.

I did not test the change to the subfolder configuration as I do not use subfolders and it would conflict with other services I have, but followed the same pattern as it was obvious how to make the correct configuration changes.

Source / References

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

[LinuxServer-CI]

This pull request has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

[adepssimius]

PR still valid please review.

[drizuid]

PR still valid please review.

it was reviewed, questions were asked.. you have thus far ignored them.

[adepssimius]

Could you move the location up beneath the command location to keep all of the locations in order alphabetically?

was the only question that was asked, which I addressed. I do not have an explanation for the additional musings included in the comments, only my empirical observations that my changes allow custom themes to work while they currently do not with the existing config as noted in my initial PR description. Take it to fix the issue or leave it broken. My setup still works either way.

[nemchik]

syntactically, what you have proposed is correct. I still don't know why a custom theme would not work if you've logged in to authelia first and then to qb. it could be a misconfiguration of authelia or the proxy confs related to authelia. that may even be an issue with our authelia confs. i don't use qb to be able to confirm.

i don't like the idea of exposing the css without auth (if you're enabling auth for access). part of the expectation of using auth for some people is to not expose resources that could identify specific software versions being run that could make the user (person running the apps) become a target of certain attacks known to work on specific versions of specific software. i'm not at all saying this is the case with qb or with custom css, but rather in general. this change would make the qb conf an exception compared to others that do not do this.

really what i'd like to see is why authelia is trying to re-auth the css after you've logged in. i'm not sure the best approach to get that answer without running it myself. I do have authelia setup and can try to test, but i'd want to know specifically how you've configured qb (which i don't use or have setup), ex: with what custom theme, and how did you apply it?

[adepssimius]

Thanks for the constructive comments. The custom theme is installed by unzipping the custom UI into a folder that is accessible to the application. In my case, it was unzipped to the config dir that is mounted in to provide application config. The location of the custom UI is configured in the qb conf file with WebUI\RootFolder=/config/dark-theme.

Upon the addition of this configuration item

Local behavior: the UI changes if qb is accessed locally swag behavior: After authentication with Authelia the root HTML document loads and several other static assets such as icon images are able to load succesfully, but the requests for the CSS assets return a 302 with a redirect to authelia, which fails (oddly enough the failing requests return a 200?)

I'm a relative neophyte in the infra space and I lack knowledge in auth, but please let me know if I can provide any other clues or if you have other avenues to investigate and I will certainly be happy to help explore. Otherwise as before, terse jabs about free work will be met with the requisite snark.

[adepssimius]

Another question from the latest comment is if exposing css paths without auth is bad, then why is the same pattern used for: api command query sync and scripts paths?

Surely the resources available there make you just as vulnerable if not more so. Maybe the entire qb config needs a rework to address the issue you bring up? Maybe I'm showing my lack of knowledge here, but it's an honest question.

[nemchik]

Another question from the latest comment is if exposing css paths without auth is bad, then why is the same pattern used for: api command query sync and scripts paths?

Surely the resources available there make you just as vulnerable if not more so. Maybe the entire qb config needs a rework to address the issue you bring up? Maybe I'm showing my lack of knowledge here, but it's an honest question.

Most of them are exposed without auth because there was at some point documentation explaining the requirement. I referenced said documentation here https://github.com/linuxserver/reverse-proxy-confs/pull/76 but it appears that documentation has since been removed, and unfortunately I don't know if GH wiki has a history the way commits do.

It likely does make sense for there to be a wholesale rework of the config, especially if there's been a major version bump or rewrite of qbit since 2019 that may have changed things.

That being said, i agree it makes sense that we're exposing the scripts endpoint so we may as well expose the css endpoint. also among the other endpoints exposed, it doesn't seem like there's much obscurity gained by adding auth to the proxy, but that also begs the question of how much actual protection is gained (is adding auth even doing anything?).

I'll accept the PR for now, but i'd love to see a full rewrite of this config that both tests custom themes and external tools like nzb360, as well as ensuring other applications like *arr can connect through the proxy config.

[adepssimius]

I just tested hitting GET api/v2/sync/maindata in an unauthenticated session from a new private window. YIKES! Yes, everything is populated with real info as you might expect. This has to be reworked with auth implemented correctly to be in a usable state. Anyone using this and assuming that they are behind auth is clearly vulnerable.

[aptalca]

You must have disabled qbit auth for local access, which also disables it for the api (because it is a webui api)

My guess is, qbit sees the request coming from that local range you set (SWAG perhaps) and serves info without auth. With qbit auth turned on, curl https://qbittorrent.mydomain.com returns Forbidden

We'll add a note about it to the proxy conf

[aptalca]

Did some quick tests. Indeed, if you add SWAG's address in the Bypass authentication for clients in whitelisted IP subnets field, all connections coming through the proxy will be treated by qbit as a local connection and the auth will be disabled.

I tried adding SWAG ip range to Trusted proxies list which should respect the X-Forwarded-For header and use the real client IP reported by SWAG, but couldn't make it work. That might be a bug within qbit.

We do not recommend bypassing qbit auth for local clients as it also disabled the api auth.