session.gc_maxlifetime is a server-side limit, but okie_lifetime is a client-side limit. 
For one hour it would have to be 60 * 60 = 3600.įrom the information I found, and my understanding of it:
(note: the article says 60 = 1h, which afaik is wrong. (2 * 7 * 24 * 60 * 60 seconds = 1209600 seconds) About the valuesįor more information on these values, see Fix.ĭecide on suitable values for session.gc_maxlifetime and okie_lifetime, and use one of the places mentioned above to set these values.įor the project I am working on, I decided to set both values to 1209600 = two weeks. grep is your friend.Īlso look for modules that modify login duration, such as or. in /etc/apache2/nf, or /etc/apache2/sites-enabled/. ini_set() statements in your Drupal's sites/*/settings.php. Otherwise, the number specifies seconds of login duration. This means that closing the browser causes a logout. Look for okie_lifetime and session.gc_maxlifetime.Ī value of okie_lifetime = 0 causes the Expire = Session for the session cookie. Open admin/reports/status/php for current phpinfo. This can give you clues whether this is a problem with your global server config or with your specific site. your localhost), and with different browsers. It can also be interesting to compare with other Drupal sites installed on the same server (e.g. Most of the time this is not what you want! The cookie that is relevant for login has a key = "SESS.".Īn "Expire" of "Session" means that the cookie expires when the browser is closed. To debug this, one can use browser developer tools to inspect cookie expire date. Inspect your session cookies with browser developer tools But I'm not sure whether it's a good practice or not.Look for session.gc_maxlifetime and okie_lifetime. So it can mitigate the loss even if both access token and refresh toke are leaked. One way that I can think of is to add another field to the access token to restrict refreshing the token to, say 30 minutes. Doesn't the idea of maintaining the revocation list break this advantage? Well, one of the major reason that people use JWT is that server doesn't need to maintain the session so it's more scalable. 
Someone suggested that a revocation list should be maintained at the server side so every request to refresh the token should be checked. In that sense the access token's short expiration doesn't help much here. If the hacker get the access token somehow, then it is very likely that the refresh token is also leaked and the hacker can request the access token by using the refresh token. Let's called the two JWT or two fields access token and refresh token. See this in-depth discussion of session management for details.įor those who mentioned two JWTs ( or one JWT but two fields ( Baldry Rietveld): Once every 15-minutes shouldn't be enough to hurt your authentication service's performance.Įdit 18 November 2019: Per Poddar's comment, you should generate a new refresh token every time the old one is used. So stick with the frequent refresh intervals.
#Drupal login expired password#
If you make the lifetime of a token a week, you will likely need to implement another means to handle, for example, the deletion of a user account, changing of a password (or other event requiring relogin), and a change in access permissions for the user. Without frequent refreshing, it is very difficult to remove access rights once they've been granted to a token. This makes the evaluation of the tokens more efficient, but makes it impossible to retract access rights for the life of a token.
This is needed because validation of the token happens via cryptographic means, without the need to contact the authentication service. Refreshing a token is done to confirm with the authentication service that the holder of the token still has access rights.
0 kommentar(er)
