Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarity over TTL and Session Expiration #360

Closed
morgz opened this issue Dec 17, 2019 · 2 comments · Fixed by #367
Closed

Clarity over TTL and Session Expiration #360

morgz opened this issue Dec 17, 2019 · 2 comments · Fixed by #367

Comments

@morgz
Copy link

morgz commented Dec 17, 2019

Hi Dan,

I may have got my thoughts a little muddled on this but could you clarify:

  1. What determines when a user is automatically logged out?
  • So far I can control this via the max_age of my plug Plug.Session, but I thought I could set this in a POW config?
  1. What exactly do the following TTL's actually do? I'm assuming I can use 1, or both of them to control the time a user can be logged in before they are presented with an auth challenge.
  plug Pow.Plug.Session, otp_app: :my_app,
    session_ttl_renewal: :timer.minutes(15),
    session_store: {Pow.Store.CredentialsCache,
                  ttl: :timer.minutes(15),
                  namespace: "credentials"}

I don't think I understand renewing a token, versus an actual login challenge being presented to the user. I was assuming that a session_ttl_renewal: :timer.minutes(15) meant the user would need to login again after 15 minutes of inactivity, but in my testing I haven't been able to get this behaviour.

@danschultzer
Copy link
Collaborator

:session_ttl_renewal is used to tell when Pow.Plug.Session should roll the session id limiting the attack window. Some platforms prefer to renew the session id at every single request, but 15 minutes is considered safe for most.

The :ttl in the :session_store is the maximum time which a session id can exist. It'll be deleted no matter what after this period of time. When :session_ttl_renewal is reached, the current session id is deleted and a new session id is created. The same happens any time Pow.Plug.Session.create/3 is called (as an example, in Pow this happens when the user update their user details, i.e. change in privilege).

We use these two TTL's to determine idle sessions. The session id becomes stale after 15 minutes, and the user has another 15 minutes to make another request before the session id gets deleted by the server. Thus detecting session activity only happens when :session_ttl_renewal is triggered.

To limit the session to 15 minutes maximum, you can decrease :session_ttl_renewal. By how much depends on your use case, and how often you want to check for session activity. Limiting it to one minute would give the user a 14 minute window to make another request, while limiting it to 0ms would give the user 15 minutes.

  plug Pow.Plug.Session, otp_app: :my_app,
    session_ttl_renewal: 0,
    session_store: {Pow.Store.CredentialsCache, ttl: :timer.minutes(15)}
  plug Pow.Plug.Session, otp_app: :my_app,
    session_ttl_renewal: :timer.minutes(1),
    session_store: {Pow.Store.CredentialsCache, ttl: :timer.minutes(15)}

Note that it isn't necessary to set the :namespace, the default defined in the macro will be used.

The way you set the values means that the session will always expire since it won't be able to roll the session id before the server expires it.

I'll open a PR to explain the above automatic session expiration logic in the docs for Pow.Plug.Session. Also, I just realize that I need to implement an absolute timeout for the session since right now a hijacked session could be kept alive forever. This should be trivial with the new metadata setup.

Let me know if this makes it clear how automatic expiration works 😄

@danschultzer
Copy link
Collaborator

Updated docs in #367. I think I'll wait with absolute timeout implementation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants