Open webvictim opened 3 years ago
I believe that this was fixed in Teleport 6.1.
This is the configuration that now works for me:
app_service:
enabled: yes
apps:
name: edgerouter
public_addr: edgerouter.teleport.example.com
insecure_skip_verify: true
rewrite:
redirect:
- 192.168.64.1
- https://192.168.64.1
uri: https://192.168.64.1
Hi, I am having the same problem here. Trying to access application which is behind nginx server as ngins id doing some hard rewrite stuff, which teleport is not able to do. However, websockets are working when I am directly accessing the web page from the nginx instance, but when I try to use the teleport app access before the nginx - everything seems to work fine except the websockets. I've tried everything described in this post and with no success. It seems wss:// just does not to pass through teleport. Using teleport enterprise 7.3.3
I have a feeling this wasn't fixed in Teleport at all - it was just coincidentally fixed in the router software (to use the URL from the browser rather than hardcoding it a value) around the same time.
I have made a few changes to introduce some basic substitution functionality. I am currently testing it, and I will submit a PR soon.
PR requested for the v9 branch. This is the first time I submit a PR to Teleport so I hope I got things right!
Feature Request
I use AAP to proxy access to the web UI of my home router (Ubiquiti Edgerouter Lite). I've noticed that while I can start to log into the web UI via AAP, it ultimately fails to load with an error shortly after I input my username and password.
The reason for the failure is that despite me loading the web UI at https://edgerouter.teleport.example.com and logging in, my browser then tries to make an XHR call to the router's real IP at
https://192.168.64.1/api/edge/get.json
. This URL is contained in a Javascript response on the HTML page which is served after logging in (sample below):When I access the Edgerouter via Caddy using its transparent reverse proxy functionality, all the URLs present in this Javascript content are automatically rewritten to point to the Caddy domain, and so the login process (and entire web UI in fact) works flawlessly.
(Incidentally, the
wss://192.168.64.1/ws/stats
websocket URL shown above would also undoubtedly fail to work without this fix. I also don't know whether AAP actually supports the use of websockets, even if the URL was correct?)My feature proposal is that AAP should do the same thing as Caddy. If I specify the below config, then any matching redirect URLs embedded in pages should also have a string replacement done before serving them up, to replace those URLs with ones that point to the reverse proxy domain:
Motivation
Other reverse proxies (Caddy, nginx) have this same functionality. It will be useful for any apps that hardcode their base URLs into pages they serve and don't provide any way to alter this.
Who's it for?
AAP users: OSS, Pro, Enterprise