One of my Django websites was recently found by some crawler that went nuts over the login page, requesting it 100-200 times per minute for a couple days before I noticed. I only found out because my database backups started exploding in size, specifically because of the django_sessions table. I have django-admin.py clearsessions set to run daily to clean out expired sessions, but the millions of sessions created wouldn't be touched by the command. The crawler didn't actually try to log in, but
I ended up blocking the bot, adding rel='nofollow' to login links, and adding Disallow: /login/ to robots.txt, but for the long-term this still suggests that something can come along and fill up my database with garbage. How do I avoid this? I don't know why I even care about sessions for users that aren't logged in, can I restrict sessions to them?
My sessions middleware is django.contrib.sessions.middleware.SessionMiddleware and I haven't specified the SESSION_ENGINE (so it's default, I presume).
Related
Ok, I hope I don't get too beat up here for this question as it is kind of complex. At least in my view, with what I know so far. So the details first:
I built a nice app with django that brings in event data for users, utilizes that data for many things (not relevant to this question) but one of the things is that it syncs these events to the users Google calendar. I made the google app within the developer console, and it uses the provided credentials.json file to allow users to authenticate the app, thus creating individual user token.json files per user, then I have another script (not within django, just a custom python file) that runs from a cron job to automatically sync/ update the calendar info from the database to the google calendars.
Now, the new problem is having this work without my help. IE: a new user logs in and creates a profile, then if they should choose to sync to their Google calendars I have to be there, running the authentication process from my personal server. So I did that, by moving the whole app to a hosted platform and brought it up to speed in production mode.
Users can create a profile, using django-allauth it works to make an initial user account where they can fill in the rest of the profile. It does populate the token string for their account, but here is where I'm stuck.
What process is there to make the token.json file OR use the existing token string (the one it saves now on the server version) to allow the system to sync the calendars? Once the token files are created, the rest of this works. I just can't get the right answers to how django-allauth will handshake with Google and do this?
Thanks for any help!
Update: ultimately wound up using a service account with google api, and directing my users to combine the service account email (adding it as a shared user to the specific calendar) and they copy/paste the shared calendar ID in their profile on my app. All the logic now just uses this share function to sync the calendars, and it works great.
I'm running a site on Django that has been in operation for a few years. We use sessions with a Redis cache backend. After a reasonably minor update of Django to 1.11.16 from an earlier 1.11.* version, we're seeing that user sessions are being ended for no obvious reason.
One dependable way to get a session to end is to navigate to a url that causes a history.replaceState() to replace the URL. As soon as that happens - the old sessions ends, the user is logged out, and a new session is started.
Any clues would help.
I would like to know how I can force users to re-login in django?
My situation is the following: I'm developing have a facebook app, where I store some of their data.
As sometimes, it's expensive (time consuming) to update all users info, I don't do it at every access, but only when they login.
Sometimes, I do want to re-update their data to store new available data or even data due to new permissions, so I would like a way to force them to re-login. This will be done eventually, so no need for automation.
Any ideas?
Thanks in advance
Just delete the Session table. Their sessions are stored there and once they return to site they'll have to login again.
I'm working on a site that uses Django 1.2.5. It uses the Django authentication backend to log users in and out. This, in turn, uses the Django session framework to set cookies. It appears that cookies set by Django's session backend expire after 2 weeks. I've gotten complaints from users that they are being logged out of their accounts and have to be log back in, and I suspect this is due to the fact that cookies are expiring after 2 weeks. I have SESSION_COOKIE_AGE to 1 year (i.e, 31556926 seconds) but I don't know if that's the best solution to this problem -- I'm not sure if it'll have unintentional side effects.
Is there a way to keep users logged in indefinitely (i.e., keep them logged in until they manually log out)? I haven't found a setting, but any solution (e.g., middleware or the like) would be acceptable.
The only way to extend session life is through longer-lived cookies. Every other method of user identification (e.g. IP + user-agent) suffers from ambiguity and, therefore, has security issues.
I created a simple middleware that updates user session cookies periodically, which eliminates the described problem.
https://github.com/IlyaSemenov/django-everlasting-sessions
I have an asp.net web app that has Session state stored in sql server. I need to keep track of the time spent by a user on each page. How can i do that using cookies?
Couldn't you use a cookie to store the time when the user navigated to the page and then when they navigate to another page calculate the time spent on the previous page, enter that into the database or something and then repeat the process?
If you can get away with tracking time for all users collectively rather than individual users, I would install Google Analytics.
http://www.google.com/analytics/
Tracking user time across a site isn't ideally done in the cookies, which are more for providng things back to the user.
That said, you'd need to store the intermediate data in the cookie if you're going to store the true 'time per page' per user rather than faking it at the server by counting the gap between page requests per session. You could do this by setting the load time at the page load, then comparing that to the current time in the onUnload event hander. Save that to the cookie and it should be available to the server in the request body of the next page it sends.