-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow staying logged in for longer #4236
Allow staying logged in for longer #4236
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
Maybe related to #3259 |
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. Current setup
Possible options
My recommendation
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. Side noteI 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. Fixes #3259
There doesn't appear to be but advertising does rely on the cache. |
readthedocs/profiles/views.py
Outdated
@@ -310,5 +310,6 @@ def account_advertising(request): | |||
'form': form, | |||
'profile': profile_obj, | |||
'user': profile_obj.user, | |||
'session_expiry': request.session.get_expiry_date(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this isn't used with the recent changes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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: https://github.com/rtfd/readthedocs.org/blob/c87e646413dcd7e9f66f733b559d10010c3fa3db/readthedocs/core/middleware.py#L222
readthedocs/settings/base.py
Outdated
SESSION_COOKIE_DOMAIN = 'readthedocs.org' | ||
SESSION_COOKIE_HTTPONLY = True | ||
SESSION_COOKIE_AGE = 30 * 24 * 60 * 60 # 30 days | ||
SESSION_ENGINE = 'django.contrib.sessions.backends.signed_cookies' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we are going to use signed cookies, don't we want to remove django.contrib.sessions
from INSTALLED_APPS
?. What I understand from the documentation it's only used for database-cookies.
https://docs.djangoproject.com/en/1.11/topics/http/sessions/#using-database-backed-sessions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking of actually taking this change out and making this a setting that is set in the production settings rather than in the base settings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are advantages to signed cookies but they aren't huge and they are what's holding this up due to the complications with the corporate site.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed the SESSION_ENGINE
setting here. If we decide to change the production SESSION_ENGINE
, we'll do that in the production settings file. This will ensure that anyone taking our code and using it don't have a SESSION_ENGINE
change unless they want one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense. 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good.
No changes should be required by the |
GOLD MEMBER/DONOR
NON-DONOR