RE: Cosign Loop Breaking

["Brett Lomas" <b.lomas@xxxxxxxxxxxxxx>]

I Johanna, and others,

I think the idea is sound, but I think it should possibly another cookie,
which doesn't have to be 'in-memory'. I think the cosign= cookie is only an
opaque value to be used by the cgi/cosignd to obtain data about the person.

Well, that's my opinion anyways :)

Brett

-----Original Message-----
From: johanna bromberg craig [mailto:canna@xxxxxxxxx] 
Sent: Friday, 4 June 2004 5:35 a.m.
To: Cosign Discussion
Subject: Cosign Loop Breaking

Hey all,

So we've been kicking this idea around for a while, and wanted to throw 
it out to the group.

There are a few misconfigurations that can cause a loop where a service 
will set a cookie, redirect back to the central cosign server, which 
will try and register the cookie, succeed, redirect back, where the 
"check" will fail, set a new cookie, redirect, re-register, etc. This 
will go on until the browser detects "too many redirects" ( this 
threshold varies by browser ) at which point a very unhelpful message 
will be thrown by the browser and the user is "stranded."

I propose that we add some code to the cgi that keeps track of the 
number of REGISTERs in a given time period.  Our current idea is to 
tack on a time stamp and a count to the end of the login (cosign=) 
cookie, so we'd have:

cosign=[random_bits_here]/[time in seconds]/[number of registers since 
that time]

If a give login cookie exceeds X registers in N seconds, the cgi can 
throw a proper error screen giving the user some *actual* information. 
:) The current defaults I'm thinking of are 10 registers in 30 seconds. 
This is fairly arbitrary, and just where I'm starting?

Let the discussion begin!

Thanks,
Johanna and the Cosign Dev team