Cookie Insert - non absolute timestamp

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

Yes, 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

 

 

 

 

 

Sorry. 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

hmm,

 

 

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

 

 

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

 

Posted 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

 

 

hmm, 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