This is a really basic HTTP question, but I can't find the answer by Googling with this terminology (I guess I'm using the wrong terminology).
I want to set two session-wide variables.
The two session variables should expire at different times. One should expire after 30 seconds, one should expire when the user closes the browser.
Should I use session variables, or cookies?
In other words, does the expiry date attach to the session variable, or to the session itself? And can I do this better with cookies?
In case it matters: I'm working in Django.
Thanks!
Let me quote from Django documentation on sessions:
set_expiry(value)
Sets the expiration time for the session.
So, this probably answers your question. The "expiry date" is for a session, not session variables. A session stores session variables. Therefore, session variables should expire along with the session. In other words, session variables can't expire at different times.
I'm no master but I would use cookies since that is simple as pie to set the timer on and has several options for your "destroy when close"-part, even though sessions will work neatly for the last part as well.
Related
I am working on an contact sync solution to be able to keep the contacts in our app in sync with the google contacts of the user.
Our code uses the php library for the google people api latest Version (v1).
Everything is working fine for one week with each user but after that week we get:
400 - Error "Sync token is expired.
Clear local cache and retry call without the sync token".
My question now:
Is this intended behaviour that you have to clear all your cache after one week with no changes or am I doing something wrong?
Is there any possibility to renew a syncToken if there were no changes?
I already checked the whole code to be sure that the new received nextSyncToken is saved at our side and used for the next incremental sync request. It seems that the new sync Token is always the same as the one sent in the request. Thus it is just clear that we get that errors if a sync token expires after exactly one week.
I also tried to set the option requestSyncToken to true for every list request, even if also a syncToken is set. No success. Sync token stays the same after each request with no changes.
Just in case someone is also facing this problem (syncToken expiration after one week without changes in the persons/contacts list):
Our solution was:
Save the creation date and time of a new syncToken each time you
get one together with the syncToken.
When you receive a syncToken in an incremental sync process compare that token to the stored one. If the syncToken is a new
one, overwrite the old one and its creation date/time.
Use a continuous process that checks each syncToken. If one is about one week old (for security reasons we used 6 days) create a new
syncToken (process see below). As the people API does not offer
things like the watch-channels of the calendar API you would anyway
need some continuous processes that do list-calls in fixed time
intervals for a complete real-time synchronization - so maybe you
could combine these tasks depending on your solution for this
problem?!
Process for creation of a new SyncToken:
Do a new list request without providing a syncToken.
For additional security do some checkups like compare the total persons received with the total persons expected by the old/current
data. And do this renew process at a time of the day when almost no
one does changes generally, for example like 2am.
Overwrite the old syncToken and date/time with the new one and the current date/time.
That's it.
But attention! You can still miss some changes that were made if your syncToken renew process is running exactly at the time a change is made!
Create a dummy contact before the sync to get a new syncToken. After the sync delete the dummy contact from both Google Contacts and your cache.
I'm developing a small website with Flask & Flask-Login. I need an admin view to monitor all user's online status. I added an is-online column in user db collection and try to update it. But I didn't find any callbacks to handle session expires. How to solve it or any better idea?
Thanks!
FYI, Counting Online Users with Redis | Flask (A Python Microframework) - http://flask.pocoo.org/snippets/71/.
You could get away with checking if users last activity time is bigger(older) than session life time.
if that's the case, you will go on an update their is_online status.
the way i have handled the problem in my application was, since i had a last_activity field in db for each user, to log when they have done what they have done, i could check that value vs session life time.
One very crude method is to create a separate stack that pushes and pops when a user logs in. Assuming that session id and userid on your db is not tied together (i.e., you have separate session id and user id), you can maintain a ledger of sorts and push and pop as sessions are created and destroyed.
You will have to put special emphasis on users running multiple sessions on multiple devices...which is why i put a caveat saying this is a rather crude method.
As I see each time the session is changed, i.e request.session['last_date'] = datetime.datetime.now() for example, the expiry_date is changed too.
Can I create an exception for that? I want to use the expiry_date as a timeout for the session, but I have a JS code in the client which send requests every few minutes, thus always extend the session expiry_date.
I want a way (simple, I hope) to write to the session without extending this date.
You can use the session.set_expiry function to set a custom expiry date, which will not be extended after modifying the session.
Coldfusion has a system created client variable called lastvisit.
Is there a way to get the value of that variable during the request that it is actually set (i.e. client.thisvisit)?
The idea would be that I can store the "ThisVisit" timestamp in session and then compare it to lastvisit when the next request is made. This would tell me if another request was made in the session.
The purpose is that we have a page that we use an ajax record lock on which refreshes the lock every minute. After sixty minutes the ajax lock code will automatically log the user out of the website (due to inactivity). The issue arises where the user is executing tasks in other windows/tabs (indication of activity).
Sense all requests update LastVisit, I would like to have the ajax lock code save the save a "thisvisit" value so that the next time it runs it can compare it to the LastVisit client variable.
A couple requirements:
Set up to use a DB rather than registry for your client vars (trust
me).
Client vars have to have "global variables" enabled
Your cfapplication or application.cfc has to have client management enabled.
If you have those three things you can select a query like the following:
<cfquery name="getLvisit" datasource="myClientVarsDB">
SELECT lvist
FROM cglobal
WHERE cfid =
<cfqueryparam type="CF_SQL_CHAR" value="#urltoken#"/>
</cfquery>
urltoken might be wrong... it may need the jsessionID or CFID but my memory tells me cftoken. I'd have to hunt down a site using Client DBs to give you a definitive answer.
So that would give you the current value of the lvisit variable. you would store this in the session and then compare it against the value from the table on subsequent queries before you overwrite it again (if that makes sense).
Note - this value is updated on each request - so your query get's the current value (before it has been updated). I previously thought this it was updated first but according to Tom it's actually updated last.
I need to track some information on users, but would like to retain it for a fixed time period, say a week.
If I set this value via request.sessions, and the user logs out, can I retrieve it if they log back in later? This all assumes that my sessions are normally set to expire in 30 days, if the user neVer logs out.
While thinking about the above problem, I decided to store the data in a table, but I would still like to know the answer to above for referenCe. I also decided not to use cookies due to unreliability.
It would depend on your session backend. But the default backend (backends.db) does delete the row from the sessions table when you log out.
I would recommend adding the data to a field in the user profile. Using the session will give problems even if you don't delete the data. The next time the user logs in you won't know which session id he/she used the last time and normally you only have the session id to look up. Not a user id so you can get all sessions owned by a specific user.