search

gravitational / teleport

The easiest, and most secure way to access and protect all of your infrastructure.
https://goteleport.com
GNU Affero General Public License v3.0
17.37k stars 1.74k forks source link

AAP doesn't support subdirectories in URIs #4547

Open webvictim opened 3 years ago

webvictim commented 3 years ago

What happened: I set up an app in AAP which isn't served on the root of the domain, but rather on the /admin URL:

app_service:
  enabled: yes
  apps:
  - name: pihole
    uri: "http://artemis/admin"
    public_addr: "pihole.teleport.example.com"
    labels:
      name: pihole
      server: artemis

Loading the site directly via curl appears to send a redirect:

gus@hades:~$ curl -vL http://artemis/admin
*   Trying 192.168.64.254:80...
* TCP_NODELAY set
* Connected to artemis (192.168.64.254) port 80 (#0)
> GET /admin HTTP/1.1
> Host: artemis
> User-Agent: curl/7.66.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 301 Moved Permanently
< Location: http://artemis/admin/
< Content-Length: 0
< Date: Wed, 14 Oct 2020 14:58:52 GMT
< Server: lighttpd/1.4.53
< 
* Connection #0 to host artemis left intact
* Issue another request to this URL: 'http://artemis/admin/'
* Found bundle for host artemis: 0x55716b5e6f50 [serially]
* Can not multiplex, even if we wanted to!
* Found connection 0, with 1 requests on it
* Re-using existing connection! (#0) with host artemis
* Connected to artemis (192.168.64.254) port 80 (#0)
> GET /admin/ HTTP/1.1
> Host: artemis
> User-Agent: curl/7.66.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
* Added cookie PHPSESSID="4i3abeqa98geuqtnlm5ddh37hn" for domain artemis, path /, expire 0
< Set-Cookie: PHPSESSID=4i3abeqa98geuqtnlm5ddh37hn; path=/
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate
< Pragma: no-cache
< Content-type: text/html; charset=UTF-8
< X-Pi-hole: The Pi-hole Web interface is working!
< X-Frame-Options: DENY
< Content-Length: 16337
< Date: Wed, 14 Oct 2020 14:58:52 GMT
< Server: lighttpd/1.4.53
< 
<!doctype html>
<!-- Pi-hole: A black hole for Internet advertisements
*  (c) 2017 Pi-hole, LLC (https://pi-hole.net)
*  Network-wide ad blocking via your own hardware.
...html starts

Loading this site via AAP gives me the root of the domain rather than the /admin content:

Screenshot 2020-10-14 at 12 04 44

Trying to load https://pihole.teleport.example.com/admin doesn't work either, as it redirects my browser to http://artemis/admin instead. This is also the case even if I change the app's configured uri to http://artemis too (I suspect these are both the same bug as #4546)

What you expected to happen: Users should be able to proxy requests to a subdirectory via AAP, as well as a domain. https://caddyserver.com/ (which I was using before AAP) supports this:

pihole.domain.com {
    proxy / http://artemis/admin {
        transparent
    }
}

How to reproduce it (as minimally and precisely as possible): Set up an app which needs to proxy to a subdirectory rather than just the root.

Environment

russjones commented 3 years ago

What happens when you go to pihole.teleport.example.com/admin?

webvictim commented 3 years ago

Trying to load https://pihole.teleport.example.com/admin doesn't work either, as it redirects my browser to http://artemis/admin instead. This is also the case even if I change the app's configured uri to http://artemis too (I suspect these are both the same bug as #4546)

webvictim commented 3 years ago

This is fixed as of 5.0.0-beta.9

benarent commented 3 years ago

An example, for anyone else who finds this issue. 

app_service:
  enabled: yes
  apps:
  - name: kibana
    uri: "http://localhost:8080/_plugin/kibana/app/kibana"
    public_addr: "kibana.teleport.example.com"
p0358 commented 1 year ago

I am facing the exact same issue again on Teleport v11.2.2 git:api/v11.2.2-0-g90bde73 go1.19.5.

uri being "http://localhost:80" works as expected, but adding /somepath to it, causes the browser to redirect to uri after being authed.

The only thing I think could possibly be different, is that I run the main proxy on a port different than default 443. Perhaps this broke whatever the old fix was?

However worth noting that loading https://test.teleport.example.com/somepath does properly load the site at /somepath in such case. But loading root will redirect my browser to http://localhost:80/somepath if I set the uri to "http://localhost:80/somepath"...

webvictim commented 1 year ago

@ryanclark Do you have any insight into this issue based on your recent changes to URI handling in app access?

ryanclark commented 1 year ago

@webvictim here's the RFD outlining the changes - https://github.com/gravitational/teleport/blob/master/rfd/0103-application-access-web-ui-auth-flow.md

I'm not sure if this would affect things - the path should be preserved on login