Bug 5394 - difficult to use tlwebaccess/tlwebadm behind reverse proxy that modifies urls
Summary: difficult to use tlwebaccess/tlwebadm behind reverse proxy that modifies urls
Status: NEW
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Web Access (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: MediumPrio
Assignee: Bugzilla mail exporter
URL:
Keywords:
: 5678 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-01-07 16:07 CET by Samuel Mannehed
Modified: 2025-03-28 16:49 CET (History)
5 users (show)

See Also:
Acceptance Criteria:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description Samuel Mannehed cendio 2015-01-07 16:07:11 CET 
Currently you access these services from https://<yourthinlincserver>:<port> and don't have any option if you would like to run these services in a subdirectory. Example:

https://example.com:300/thinlinc

instead of 

https://example.com:300

This could be achieved by either a configuration parameter or by having the services figure out their prefix path and then using relative paths in the code.
Comment 2 Pierre Ossman cendio 2018-03-13 15:49:09 CET 
This scenario only happens with a proxy, so we don't need to have explicit support for this in ThinLinc. We just need to make sure we don't break the proxy's rewriting of URLs. If we start using relative URLs everywhere then things should be fine without any extra logic.
Comment 3 Pierre Ossman cendio 2018-05-15 13:27:18 CEST 
*** Bug 5678 has been marked as a duplicate of this bug. ***
Comment 4 Pierre Ossman cendio 2018-05-15 13:31:13 CEST 
It's actually possible to get this working, but it requires a lot of configuration in the proxy to rewrite all the URLs correctly. And these are internal aspects of ThinLinc so they are difficult for the administrator to keep an eye on.

Here is one guide a user has written to do this:

https://www.verboom.net/blog/index.html?single=20151019.0
Comment 9 Pierre Ossman cendio 2022-04-22 10:12:23 CEST 
The biggest issue is the redirection from the master to the agent. Relative URLs are not possible there, since we are redirecting to a different host.
Comment 17 Pierre Ossman cendio 2025-01-09 17:20:36 CET 
(In reply to Pierre Ossman from comment #9)
> The biggest issue is the redirection from the master to the agent. Relative
> URLs are not possible there, since we are redirecting to a different host.

I had one idea that might make this easier to set up for proxies. Instead of redirecting directly to the agent, the master has a local intermediate URL that the proxy can override.

E.g.

1. User goes to https://tl.example.com
2. When logged in, it gets redirected to https://tl.example.com/agent/agent12.example.com
3. The "/agent/foo" URL just creates a new redirection to https://agent12.example.com/agent

For a standard installation, there wouldn't be much change except some added latency because of the extra indirection.

But for a proxied setup, the proxy could catch the request in step 3 and proxy directly to the agent instead of sending a redirect.
Comment 18 William Sjöblom cendio 2025-03-28 16:48:48 CET 
A somewhat related issue that may or may not fit in under this bug.

Doing SSL termination at the reverse proxy and using plain HTTP between the proxy and ThinLinc node causes an infinite redirect loop as ThinLinc insists on using HTTPS.
Note You need to log in before you can comment on or make changes to this bug.