changing session cookie max_age?

[zsol...@gmail.com]

Hi,

I'd like to implement the following session cookie behaviour:

- non-logged-in users get a short-lived one, like 1800 seconds, enough for all CSRF validation

- when logging in, they extend their cookie to 1 year

I'm using pyramid_session_redis, and I can achieve the redis side changing using 

headers = remember(request, user.id)

redis_timeout = 3600 * 24 * 365 # one year in Redis request.session.adjust_timeout_for_session(redis_timeout)

return HTTPFound(location=..., headers=headers)

This changes the redis side just fine, however, I see no way to change the max_age on the already set cookie and I see that remember() supports max_age, but it doesn't work.

I've asked the developer of pyramid_session_redis and he said that there is no remember() in that package, so it's unrelated to that. Still, in Pyramid docs, I see that remember() supports max_age, so how is it?

https://docs.pylonsproject.org/projects/pyramid/en/latest/api/authentication.html#pyramid.authentication.AuthTktAuthenticationPolicy.remember

and

https://docs.pylonsproject.org/projects/pyramid/en/latest/api/security.html#pyramid.security.remember

So my solution right now is to set the session cookie max_age to something very big then just limit things in Redis.

Is this the right solution? Ideally, I'd like to achieve never logging out logged-in users, as it's bad for user experience, but at the same time limit bots and non-logged-in users to 1800 seconds.

Zsolt

[Michael Merickel]

`remember` is an authentication api and not directly tied to sessions. It does support kwargs that the authentication policy can utilize as it chooses.

Your question is about sessions, and the session cookie. It is up to pyramid_session_redis how it chooses to set the cookie, Pyramid does not handle it. It could support changing the max_age when you invoke `adjust_timeout_for_session` but it apparently is not.

My suggestion is to not worry about how long the cookie lives, set it for a long time or not expiring, and focus on just invalidating it server-side which is the only real place you can control it.

- Michael

--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/62b25a2d-4bec-4ed9-b3db-8c0e310384een%40googlegroups.com.

[Jonathan Vanasco]

On Saturday, September 19, 2020 at 12:00:28 PM UTC-4 mmer...@gmail.com wrote:

It could support changing the max_age when you invoke `adjust_timeout_for_session` but it apparently is not.

I'm the package author. `adjust_timeout_for_session` doesn't affect `max_age` because that defect was in the original project "pyramid_redis_sessions" that my project was forked from. The "expires" cookie attribute is also not supported in any way, for the same reason.  I've never needed either of these, so the issue never came up before.  I have no issue with supporting these features, but it's likely not going to happen until I need to use these features myself or someone else issues a PR. Writing support for this is pretty simple, but there are a few things it may affect in the overall API (there are both `timeout` and `expires` concepts this could alter) and writing enough test coverage to make it safe to merge it will be a few hours of work.

 

On Sep 19, 2020, at 07:34, zsol...@gmail.com <zsol...@gmail.com> wrote:

Ideally, I'd like to achieve never logging out logged-in users, as it's bad for user experience, but at the same time limit bots and non-logged-in users to 1800 seconds.

IMHO the only way to achieve the UX of "never logging out logged-in users" is to use an ancillary client-side secure/encrypted "autologin" cookie, which will establish a new session for a given user if their session cookie is expired or missing.  There are far too many scenarios that can cause a loss of ServerSide/Redis session data, including: bot traffic, ddos, usage spikes, server crashes, etc (all of which I've experienced).  Implementing this in Pyramid is fairly simple, thanks to the tweens.


 

[Zsolt Ero]

Just for reference I'd like to post what worked for me. Thanks for the detailed help.

Finally I've settled on the following values:

```

redis.sessions.secret = xxx

redis.sessions.cookie_max_age = 315360000   # 10 years, basically forever

redis.sessions.timeout = 1800

redis.sessions.cookie_secure = True

redis.sessions.cookie_httponly = True

redis.sessions.cookie_samesite = lax

```

login:

```

headers = remember(request, user.id)

redis_timeout = 3600 * 24 * 365  # one year in Redis

request.session.adjust_timeout_for_session(redis_timeout)

return HTTPFound(location=next, headers=headers)

```

I've thought about it and analyzed it and come up with the solution that this will work well for my usecase. I've never experienced any problem with the previous version of the library with similar values, which have created way more sessions then this one, as this only creates a session when it's actually needed on a login/registration page, leaving home page, etc. session-less.

[Mike Orr]

That looks similar to what I';m doing. I have three session timeouts:

- default: 1 minute for bots that never go beyond one request.
Response has a "Login" button.
- unauthenticated: 10 minutes. While the user is logging in at the
OAuth2 server.
- authenticated: 1-8 hours. Logged-in user.

When the user logs out, I switch back to the unauthenticated timeout
and display the "Login" button.

I use 'adjust_timeout_for_session' to switch between the three states.
I added config variables for the second two timeouts. I use session
cookies so I don't set a cookie expiration; it just expires when the
browser exits. My organization discourages persistent cookies for
privacy reasons.

> --
> You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discus...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/CAKw-smCUE%3DwgPfvFLpR9%2B21r_2gey27hHYopxOK43LYzHor76w%40mail.gmail.com.



--
Mike Orr <slugg...@gmail.com>