Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Allow staying logged in for longer #4236
I like these changes.
It's not still clear to me what's the workflow for this. I suppose once the user gets it's gold membership a one week session is saved. Then the user has to go to this page and increase the session's time.
After those three months, the user will start seeing ads again and it has to do the same process, right?: Go to .org site, log in, go to admin, click this button again or just log in will be enough for next 3 months?
This feels like a change that nobody will ever find or really use. Can we not catch this when the user logs in, and just extend gold user sessions automatically? Another question -- is there a reason that we have such short login sessions to begin with? Is there a reason not to just leave everyone logged in for 3 months?
Also going to echo the concern of if we really need this in the UI. I don't think users will find this easily, and I'd like to see what doc-viewing-only user subscription rates look like before optimizing this all.
Is there a view where we can
I'd be fine removing the "your login session will expire" part and the "stay logged in" button. My goal is to give gold members a way to not see ads for longer than 2 weeks without having to login constantly.
First, I'll describe our current setup and then I'll discuss options to meet that goal.
This means that somebody who visits readthedocs.org (including via the footer call) will never need to login again as long as they visit once every 30 days. Anybody who doesn't click the "remember me" button will still logout when they close their browser.
This would solve #3259 and reduce the frequency that .com users need to login.
I have a preference that our production session settings used signed cookies as opposed to cache based sessions. Since we don't write much of anything to the session there are almost no downsides and the upside is to avoid having to connect to the cache on every request which we do now. It would also free up cache space. Making this change though would log everyone out which isn't a big deal right now since people get logged out every 2 weeks anyway.
I'm +1 on the suggested implementation (30 days & re-uping on request). It seems like moving to signed cookies would be a nice performance win too. Is there anything else on the footer call that depends on the cache, or would this allow us to continue serving footer requests even when the cache is down? IIRC we hit it in middleware for CNAME's, and perhaps a couple other places, but reducing the usage of it makes a lot of sense to me.
I made the changes to remove the UI elements to extend the log in session and just made them the defaults.
NOTE: Deploying this will log everyone out although after that they will stay logged in much longer.
There doesn't appear to be but advertising does rely on the cache.
These changes make sense to me and will help Gold users to not see ads for a long time :)
I took a look at other places where we use sessions and I found this middleware that do not creates a session for non-logged in users when hitting the footer. I think it stills makes sense, but wanted to mention to you just in case you see that something need to be touched there: