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.61k stars 1.76k forks source link

Web Idle timeout of 30s or less ends up in a redirect loop #32427

Open pschisa opened 1 year ago

pschisa commented 1 year ago

Expected behavior: When web_idle_timeout is set to 30s or less, web applications will continue to work as expected.

Current behavior: When web_idle_timeout is set to 30s or less, web applications fail and continuously redirect to the Teleport login page.

Initial internal investigation seems to point at the following code as the culprit:

function startActivityChecker(ttl = 0) {
  // adjustedTtl slightly improves accuracy of inactivity time.
  // This will at most cause user to log out ACTIVITY_CHECKER_INTERVAL_MS early.
  // NOTE: Because of browser js throttling on inactive tabs, expiry timeout may
  // still be extended up to over a minute.
  const adjustedTtl = ttl - ACTIVITY_CHECKER_INTERVAL_MS;
const ACTIVITY_CHECKER_INTERVAL_MS = 30 * 1000;

https://github.com/gravitational/teleport/blob/2fdc3c2e3ba00d4a8cda7b1dee7b32afd784a9bf/web/packages/teleport/src/components/Authenticated/Authenticated.tsx#L69-L74

Bug details:

GavinFrazar commented 1 year ago

we should check if this can be reproduced on v11 as well

pschisa commented 1 year ago

Also noted during this investigation that when accessing the application directly via the application public URL, the web_idle_timeout doesnt seem to apply at all (as compared to launching the app through the Teleport Web UI). Video when the web_idle_timeout is set to 60s

https://github.com/gravitational/teleport/assets/75806143/09deb413-3e0e-42cd-a2c7-b94bf5086dde

Happy to file a separate issue if helpful

kimlisa commented 1 year ago

another issue:

if a user has a web UI opened in another tab, and application in another tab, the web UI timer will continue, and while the user may be active on an application, the web UI is inactive and will log the user out, which deletes both web and app sessions (kicking user out of the application as well)

ravicious commented 5 months ago

I could reproduce the issue on 15.3.5. FWIW, it does require clicking "Connect" next to an app in the Web UI. Initially I thought it's enough to just leave the Web UI running.

The other two reported problems have the same root cause and they seem mutually exclusive.

In the problem reported by Lisa, the user opens a cluster at example.com and an app at app.example.com and leaves both tabs running. Eventually, the Web UI running in the example.com tab considers the session invalid and logs out the user. This essentially invalidates the session on app.example.com as well, but the user probably won't notice that until they perform some action. I assume that in this scenario, the customer would want to keep the user logged in to app.example.com even after they get kicked out of the Web UI due to inactivity.

In the problem reported by Paul, the user opens an app proxied through Teleport, but accessed over public_addr. Even if a tab with Web UI is open next to it, inactivity in the Web UI tab will not remove cookies from the custom public_addr domain. I haven't been able to test it, but it should at least destroy the session in the Teleport proxy. So on the next reload or a request, I guess the user should also notice that the session is gone? But as I understand, in this scenario the customer would want somehow to the idle timeout apply to app access even if the Web UI is not running.