Keeping sessions alive longer

[starbelly]

Keeping sessions alive longer

[voltone]

Why worry about the wildapricot token expiry once you've fetched the user details? You can just fetch the user information once, upon completion of the sign-in flow, then maintain a session with the user independent of wildapricot. That's how OIDC works, and I'm sure it's what Wordpress plugins etc. do when integrating with wildapricot. They do call their OAuth server an "SSO" service, after all: I don't think they intended it as a hosted session management solution.

Of course the session needs to follow best practices, in particular it needs to involve some server-side state that can be cleared on sign-out or after maximum session duration (or inactivity). That server side state could be stored in a GenServer or ETS, but I would stick it in the DB.

[starbelly]

@voltone sorry, I pinged you and then I'm quite late to respond. Yeah, we currently operate the way you described above exactly. We of course follow best practices, keep the session in the db, etc.

I suppose we could not depend on the ttl of the token, and instead simply query wildapricot to make sure the user making a request isn't deactivated, has had their role changed, etc.

Edit:

Note that the ttl currently is in line with best practices for low risk apps (15 to 30 minutes). We could increase to 30 minutes. I've always followed (or tried to) these recommendations and usually to the annoyance of others :) However, it makes for a bad UX. If it takes you say over 30 minutes to type something up and click submit, well... you're not going to be happy. Do you feel the owasp recommendation for low risk apps is a bit much?