Forum Discussion
Beinhard_8950
Nimbostratus
NimbostratusCookie Insert - non absolute timestamp
Hi,
Little history first of my problem.
At first i have used session expire.
If you do that you can´t use disable on a node (gracefully) because the session expire is just in the UA:s memory and if the client doesn´t shutdown the browser, the cookie will be there.
So in theory a user can reach a disabled node after a long long time and thats not so good( and i don´t want to use offline mode)
So if you have a large website a disabled node will always have connections, never 0 connections.
I thought, i put in a value, like 30 min in the cookie. Everything went fine except for some users.
Our best guess so far is that the users don´t have the pc clock synchronized to a good NTP =).
Becasue the F5 put in an absolute value based on the f5 system clock and if that don´t match the client we will have problems.
I have tested (quick test) and it seems to be that if the client clock and the f5 is way off the cookie isn´t even kept in the UA memory (if you put the client clock ahead ,like +2h).
So the solution to this is what a lot of other system use instead, a non-absolute timestamp. Just a counter that keeps increasing.
Is that possibly?
I don´t want under any circumstance that the client side to deiced over this, I´t would be a big security hole.
So some hints and tricks are welcome or some more gas to the fire =)
Best regards
Beinhard
HamishCirrocumulus
Not sure why you're having a problem. Cookie timeouts are DELTA seconds. Not absolute. And cookie VALUES should be opaque so the client shouldn't be interpreting what's in them.
There should be no requirement (AT HTTP level) for the client and F5 clocks to be synchronised.
H
Beinhard_8950Yes, thought this too but what about SOL5714?
Ad why can´t I see the cookie if a change the clock forward, as i say like 2h
And if I´m logged in to the website and the clock is changed on the PC, i will be kicked off.
So if it was delta time this should not be happening.
Of course i need some more testing but it seems so strange...
Maybe some symbiosis with the app servers.
Beinhard- HamishSorry. We're going to need a bit more detail. Sadly my telepathy isn't what it used to be. For the format of 'set-cookie' see RFC2109... http://www.ietf.org/rfc/rfc2109.txt
Now, max-age is DELTA seconds. Of course the cookie will be deleted when you set the clock forward on the PC after the cookie is received... The time just went forward... It's a delta from when the cookie was set (i.e. The browser works out the expiry time when it receives the cookie with the delta time in it. This is explicitly so that machines with invalid times actually work. Back when this was designed we didn't have NTP everywhere on all the clients (OK, some of us did... But we were pretty much the exception. Most PC's got their time set when they booted. If they were lucky)
So put your clock forward and it'll expire... The browser doesn't know you just jumped the time forward manually. It's not magic.
FWIW trying to do session timings in the client is NOT a good idea. You control sessions where you control the data. Much better to keep a table locally and use the cookie as an opaque key into the table. The value in the table for the key is the session info. If the key/value doesn't exist in the session table then then session doesn't exist. Simple. And you can then use session cookies. To destroy the session just provide a URL that when accessed wipes it out.
H - Beinhard_8950hmm,
if you use cookie as persistence i don´t have a session table (persistence table).
So you mean that i should do a irule that make that table?
Why can´t just the f5 do a timestamp that just the f5 understand so the client doesn´t know to understand, as you say, a opaque value.
"FWIW trying to do session timings in the client is NOT a good idea"
I agree to 100%, thats why i started this thread.
We have an internal "timestamp" for the application so the user will be logged out after 15 min if the are inactive.
In the apps we use a timestamp that is just opaque (timer starts from zero and counting up to 900) so it´s independant from time.
But this doesn´t help if i want the gracefully service for a node, so no new "users" go to that node and the current users will decrease becaue i have session expire in the F5 (yeah, i´m repeating again =) ).
Can you evolve this: "The value in the table for the key is the session info"
If it´s to any help i´m using SSL to clients and to the backend servers.
Regards,
Beinhard - Hamish
if you use cookie as persistence i don´t have a session table (persistence table).
So you mean that i should do a irule that make that table?
You could...
Why can´t just the f5 do a timestamp that just the f5 understand so the client doesn´t know to understand, as you say, a opaque value.
Again... You could. But that's not the way it works out of the box... If you want candy, you have to make it yourself (Or hire someone to doit for you).
We have an internal "timestamp" for the application so the user will be logged out after 15 min if the are inactive.
OK. So set a session cookie with a 910 second timeout...
In the apps we use a timestamp that is just opaque (timer starts from zero and counting up to 900) so it´s independant from time.
But this doesn´t help if i want the gracefully service for a node, so no new "users" go to that node and the current users will decrease becaue i have session expire in the F5 (yeah, i´m repeating again =) ).
yes it does... Set the poolmember to 'Disabled' Then only persistent or active connections are allowed. Eventually they'll time out and you'll have no session left (How long is up to your users I'm afraid, but there's always 'Forced Offline' as well).
Can you evolve this: "The value in the table for the key is the session info"
Yep. The cookie is a key (Encrypted or not). An opaque entity that when looked up in a hash table will give you the session information. Doesn't matter if the browser presents the cookie 30 minutes later. If the session table doesn't have the entry, it's expired. But if you set the cookie expiry to 901 (Or just over 900 seconds), then it'll expire in the browser about the same time as the session expires anyway. And won't be presented. And the number of people being distributed to that node WILL decrease.
H - Beinhard_8950Posted By Hamish on 09/21/2010 03:26 AM
if you use cookie as persistence i don´t have a session table (persistence table).
So you mean that i should do a irule that make that table?
You could...
Yes but in my world it´s gonna be complicates/resource increasing etc. If i can choose I want so little irules that is possibly.
Why can´t just the f5 do a timestamp that just the f5 understand so the client doesn´t know to understand, as you say, a opaque value.
Again... You could. But that's not the way it works out of the box... If you want candy, you have to make it yourself (Or hire someone to doit for you).
Should be a feature, if you compare to Nortels old boxes then you can use session expire but when you put a node in disable state a timer is activate. Pretty nice feature.
i think also that this is a simple feature (if you had it before) so this is not candy for me =)
We have an internal "timestamp" for the application so the user will be logged out after 15 min if the are inactive.
OK. So set a session cookie with a 910 second timeout...
But as you say, then I´m forced to make up a session table or else i have the same situation as now. I´m dependent of the users clock....
In the apps we use a timestamp that is just opaque (timer starts from zero and counting up to 900) so it´s independant from time.
But this doesn´t help if i want the gracefully service for a node, so no new "users" go to that node and the current users will decrease becaue i have session expire in the F5 (yeah, i´m repeating again =) ).
yes it does... Set the poolmember to 'Disabled' Then only persistent or active connections are allowed. Eventually they'll time out and you'll have no session left (How long is up to your users I'm afraid, but there's always 'Forced Offline' as well).
we do that now but we have pretty much users =) so a node will never have 0.
Of course i can put in a script that says that if it´s below aprox 50 we put the node offline.
However this will affect users and if it affect only one user, it´s one user to much.
Can you evolve this: "The value in the table for the key is the session info"
Yep. The cookie is a key (Encrypted or not). An opaque entity that when looked up in a hash table will give you the session information. Doesn't matter if the browser presents the cookie 30 minutes later. If the session table doesn't have the entry, it's expired. But if you set the cookie expiry to 901 (Or just over 900 seconds), then it'll expire in the browser about the same time as the session expires anyway. And won't be presented. And the number of people being distributed to that node WILL decrease.
H
maybe this can be a the way to do it, but it´s involving a lot of "homemade" tricks I guess.
So if nobody else have a solution I´m gonna move to "request feature" section at F5 - Beinhard_8950hmm, I just thought about one thing.
The F5 use cookie version 0 because it use an absolute time to caclulate the expire time and it´s present in GMT and calculated by the F5.
In cookie version 1 , It´s present iin a relative time and it´s calculated by the client machine.
So if you change the cookie to version 1 then it shouldn´t matter what the client have for time.
So what do you think?
It´s not perfect (the client is still the "master") but in my eyes it´s better then nothing until the F5 maybe in the future put in a better solution.
It should be a little better then session expire.
But i guess that this need an Irule or can you change a variable somewhere?
Beinhard