Support configuring WebUI URL base path

[Piccirello]

This PR adds support for configuring the URL base path used to access the WebUI. This makes it easier to use qBittorrent behind a reverse proxy with a custom path (e.g. https://example.com/qbit/).

The WebUI previously relied heavily on relative paths. For example, api requests were made to api/v2/... and scripts were loaded from scripts/lib/... (note the lack of a leading /). Now, the WebUI exclusively makes use of absolute paths, defaulting to a base path of /. These means that, by default, these resources will be loaded from /api/v2/... and /scripts/lib..., respectively. An empty base path can no longer be set - if attempting to do so, it will use /.

Closes #5693.

[kevinpeno]

From what I can tell from the code, using your current examples, setting "URL base path" to qbit/ will result in the same relative path issue. Example instance results in qbit/css/style.css?v=${CACHEID}css/style.css?v=${CACHEID} or worse, if I set to qbit you'd end up with qbitcss/style.css?v=${CACHEID}css/style.css?v=${CACHEID}

You probably want to add some sanity checks if you really want to push this through, but unless a proxy doesn't support rewrites this might be unnecessary (see my comment here).

If you do push forward, you may want to use the base html tag as you only need set this one time in the header rather than at each point a url is needed, which will likely prevent accidental misses should new includes be added at a later time. base should work for scripting too, however sometimes scripting ignores it because it forces url generation rather than relying on the browser to build it, so keep that in mind when testing.

[Piccirello]

From what I can tell from the code, using your current examples, setting "URL base path" to qbit/ will result in the same relative path issue. Example instance results in qbit/css/style.css?v=${CACHEID}css/style.css?v=${CACHEID} or worse, if I set to qbit you'd end up with qbitcss/style.css?v=${CACHEID}css/style.css?v=${CACHEID}

You probably want to add some sanity checks if you really want to push this through, but unless a proxy doesn't support rewrites this might be unnecessary (see my comment here).

If you do push forward, you may want to use the base html tag as you only need set this one time in the header rather than at each point a url is needed, which will likely prevent accidental misses should new includes be added at a later time. base should work for scripting too, however sometimes scripting ignores it because it forces url generation rather than relying on the browser to build it, so keep that in mind when testing.

Thanks for the feedback. There's already a sanity check to ensure the path ends with a trailing slash. Good call on the leading slash - I'll add a check for that.

The reason I'm not using the base tag is because API requests made from the client don't respect it. It does seem like a good safeguard for other resources, though I'd like to avoid a potentially confusing scenario where some resources prepend the base path automatically while others don't.

[Piccirello]

@qbittorrent/bug-handlers Can someone please review this? It has been open for over a month. There are merge conflicts but the general approach will remain the same.

[Chocobo1]

@qbittorrent/bug-handlers Can someone please review this? It has been open for over a month. There are merge conflicts but the general approach will remain the same.

There is one concern from me but I'm not sure it is fully related. I haven't evaluated thoroughly.
AFAIK the web app is heavily based on one policy: Same-origin policy. The security measures, the storage on browsers, all most everything was designed with the assumption that policy will hold.
Now this PR adds an option to change that and all the related functionality now have to share origin with other "paths". For example, qbt at example.com/qbt and another app at example.com/xyz and they will have the same origin. Here is something that might happen: https://stackoverflow.com/questions/57697269/find-a-way-to-have-different-local-storage-object-for-same-origin-using-differe
Note that I do see many users requesting it but I'm not sure whether it is doable.

Also, another related question: is nginx able to inject base url in the requests on its own (without any help from qbt side)? Is it problematic to do so?

[Piccirello]

The security measures, the storage on browsers, all most everything was designed with the assumption that policy will hold. Now this PR adds an option to change that and all the related functionality now have to share origin with other "paths". For example, qbt at example.com/qbt and another app at example.com/xyz and they will have the same origin. Here is something that might happen: https://stackoverflow.com/questions/57697269/find-a-way-to-have-different-local-storage-object-for-same-origin-using-differe Note that I do see many users requesting it but I'm not sure whether it is doable.

I think it's a valid concern, however users seem to really want this feature. I think the best option would be to allow users to configure this but also make it clear (maybe in the wiki) that this approach is suboptimal and that using a unique (sub)domain is preferable.

Also, another related question: is nginx able to inject base url in the requests on its own (without any help from qbt side)? Is it problematic to do so?

I'm not certain. In #5693 it seems that some users are using nginx's rewrite directive to achieve this. It's not clear to me if other webservers support this too.