cosign-discuss at umich.edu
general discussion of cosign development and deployment
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Cosign Loop Breaking
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 :)
From: johanna bromberg craig [mailto:canna@xxxxxxxxx]
Sent: Friday, 4 June 2004 5:35 a.m.
To: Cosign Discussion
Subject: Cosign Loop Breaking
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
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!
Johanna and the Cosign Dev team