[question] How to check for session expiration in absence of a request?

[MichaelHipp]

When a request is received, the session is checked for expiration. Good.

But if I kick off a long-running process based on that request, how do I check for expiration of the session during the running of that process? Is there some way the long-running process can periodically check if he session is still good? Note that the initial expiration time can be extended indefinitely if the session is being Save()-ed when other requests arrive for that session.

Thanks.

[elithrar]

Can you provide an example of this use-case - what kind of operation?

[MichaelHipp]

Use case: A request comes in (via a session) that is upgraded to a websocket connection. It starts a goroutine that sends quasi real-time data to the client (browser). It needs to run for as long as the user is looking at the browser. But if the user goes home for the weekend and doesn't close the browser I'd like the websocket to be terminated when the session expires. I don't want to trust the client to do this, so I need a way to force it closed from the server.

So, in the for{} loop that is the essence of the goroutine, I'd like to have a simple check to see if the session is still good.

Does this make any sense? Am I missing something obvious?

[elithrar]

Right; OK - that helps! A couple of options to consider: • Carry some state when the WS connection is started: the session expiry as a timestamp: now + MaxAge or the value of Expires. Have your connection management check that as it loops over clients. • If you want to keep the client *refreshed* when the cookie is, then combine the connection management state with the cookie refresh logic - if a user gets a refreshed expiry on (e.g.) page navigation, then send your connection manager the updated expiry timestamp for that user ID’s (possibly multiple) WS connections. You could pipe that down a channel to keep it async - e.g. a { clientID, expiry } tuple that your connection manager inspects and updates as it loops over connection state. Does that make sense?

…

On Sun, Feb 23, 2020 at 7:37 AM Michael Hipp ***@***.***> wrote: *Use case:* A request comes in (via a session) that is upgraded to a websocket connection. It starts a goroutine that sends quasi real-time data to the client (browser). It needs to run for as long as the user is looking at the browser. But if the user goes home for the weekend and doesn't close the browser I'd like the websocket to be terminated when the session expires. I don't want to trust the client to do this, so I need a way to force it closed from the server. So, in the for{} loop that is the essence of the goroutine, I'd like to have a simple check to see if the session is still good. Does this make any sense? Am I missing something obvious? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#210?email_source=notifications&email_token=AAAEQ4FWGSTDBTXSRDIXHOLREKJ2FA5CNFSM4KZ27PEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMV6ZOI#issuecomment-590081209>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAEQ4GWQCL5HOZNC2HDWBTREKJ2FANCNFSM4KZ27PEA> .

[MichaelHipp]

Thanks. Something like option 2 is where I'm headed because it does need to keep up with refreshes. I'll prolly maintain that state somewhere independent of the connection routine. I'd like to keep the logic inside the connection as minimal as possible and just be something like session.IsGood().

You said: "the session expiry as a timestamp: now + MaxAge or the value of Expires". I don't see an Expires member on the Session struct, where is this found?

[elithrar]

Expires is on the cookie and derived from MaxAge - ultimately you are determining the validity server-side, so prior to calling .Save() (or just after), update the state with the MaxAge and set a “notAfter” or “validUntil” property inside the app. You could use server-side sessions with Redis or another DB, and use that as part of a “reaping” process between client && connections.

…

On Sun, Feb 23, 2020 at 8:28 AM Michael Hipp ***@***.***> wrote: Thanks. Something like option 2 is where I'm headed because it does need to keep up with refreshes. I'll prolly maintain that state somewhere independent of the connection routine. I'd like to keep the logic inside the connection as minimal as possible and just be something like session.IsGood(). You said: "the session expiry as a timestamp: now + MaxAge or the value of Expires". I don't see an Expires member on the Session struct, where is this found? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#210?email_source=notifications&email_token=AAAEQ4DFUBA654KXNTZZDPTREKPZFA5CNFSM4KZ27PEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMWAJJY#issuecomment-590087335>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAEQ4FLP5I6SLL5ZW4QQFDREKPZFANCNFSM4KZ27PEA> .

[MichaelHipp]

Thanks.

Unless I missed it, the sessions API doesn't directly expose the cookie anywhere. I was just hoping to avoid a lot of redundant calculating of expiration when it has already been done elsewhere.

[elithrar]

Yeah - we hide that as an implementation detail . session.Options.MaxAge has the basis for a time.Add() calculation.