Problem/Justification
I have a domain and cert for some services that is only available in the local network, so I can use https to access webui. Most self hosted apps would have a baseurl setting so that you can put them at mydomain.com/myapp, but not truenas.
Impact
If anyone who is trying to put reverse proxy before the webui and wants to use a subpath, the baseurl setting is needed. A quick look here [Feature] Support base url on the web app · immich-app/immich · Discussion #1679 · GitHub will give you rough ideas how much people want this. And a lot of users will do this using reverse proxy hacks even if there is no official support, for a variety of reasons. This will lead to potential security issues because without official support the cookie will be shared between apps as opposed to limited to a subpath. Official support would address this security issue by defining a baseurl.
User Story
The baseurl setting and serving under subpath is a very common practice in the self host community, I’m sure the addition will be welcomed by a lot of users.
1 Like
This can be done with a reverse proxy already.
I have subdomainA.mydomain.com pointing at the TrueNAS UI and subdomainB.mydomain.com pointing at the IP used by Nginx Proxy Manager. NPM is running as an app and can then handle any redirects as needed.
1 Like
A reason not to do this is that if you run TrueNAS on example.org/truenas, it will share cookies, session storage and local storage with other services on example.org/other-app (and possibly conflict with them).
imo stick with subdomains and make a redirect if you need it to be accessible on the apex domain for some reason.
1 Like
This can be done with a reverse proxy already.
I think you misunderstand what I was talking about.
A reason not to do this is that if you run TrueNAS on example.org/truenas, it will share cookies, session storage and local storage with other services on example.org/other-app (and possibly conflict with them).
What you have just said is exactly the reason why this needs to be an official feature, because cookies can be set for a subpath as opposed to a root path.
For a lot of users, this is a must feature. They will do it no matter what, using hacks like reverse proxy rewrites. Having official support and limit cookie to the baseurl subpath can enhance security for these users.
Just have a look at the people requesting this for immich, [Feature] Support base url on the web app · immich-app/immich · Discussion #1679 · GitHub, and you will have a rough idea how much people want this. And they will do it using reverse proxy hacks, if there is no official support. Sure you can say that “well they shouldn’t do that there is a security risk and they are responsible for their own hack etc.”, but I think this should be addressed properly.
1 Like
Right, but even if TrueNAS’ web UI sets its cookies with a subpath, other services can set cookies used by TrueNAS’ web UI on the root path. And local and session storage have no similar subpath scoping mechanism.
Not opposed to the idea, just bringing up some concerns.
1 Like
Right, but even if TrueNAS’ web UI sets its cookies with a subpath, other services can set cookies used by TrueNAS’ web UI on the root path. And local and session storage have no similar subpath scoping mechanism.
Correct me if I am wrong: if TrueNAS WebUI is aware of the subpath via a baseurl setting, it would simply ignore cookies set for the root path, right? It will only set and read cookies for the subpath.
Yes local and session storage are potentially a problem, which is again all the more reason why TrueNAS should be aware of a subpath setting, and avoid saving sensitive information in storage. Users WILL DO IT, because they have a variety of reasons to, so it makes sense to address this properly.
1 Like
It will only set and read cookies for the subpath.
Set, yes. Read, no. Browsers don’t send the path back on subsequent requests, so servers can’t discard cookies that apply to the root.
1 Like
