Shibboleth Developers

["RL 'Bob' Morgan" <>]

On Mon, 5 Jan 2004, Scott Cantor wrote:

> Just to follow up, I do actually have something like a request ID and some
> statefulness in my Web-ISO that allows me to do a better job than I would
> otherwise be able to do with just the timestamp. I'm sure pubcookie has
> something similar.

Actually the way pubcookie works is (I think):

The target (to use shib-speak) does the transfer of the browser to the
weblogin service via client pull; that is, it tells the client to pull the
weblogin URL location, with refresh of 0.  Browsers apparently don't put
an entry into their history in this case, so that in the common case of
constantly-refreshing pages history entries won't proliferate.  So if the
user hits weblogin and already has logged in, hence is redirected back to
the target, there is no history entry, so using the back button will take
the browser to whatever was before the weblogin page.

If the user hasn't logged in before, hence sees the weblogin page, then it
does show up in history, and will be seen by the user when using the back
button from the target.  But since pubcookie communicates the login
request info from target to weblogin in a cookie, and that cookie gets
cleared by a regular return to the app, when the back button is used the
user gets to weblogin with no request info.  In this case weblogin either
shows a "your login status" page if there's an active login cookie, or a
"please log in" page if not; so in either case the user isn't sent back to
the app, and can keep going back if they want.

So unfortunately I don't think any of this mechanism applies to Shib.

It occurs to me that request state could be cached in cookies in the
browser to avoid having to maintain it on the HS, and then it would
naturally go away when the browser closed.  I suppose that might lead to
cookie-store explosion on the browser though if someone visited the HS a
lot.

 - RL "Bob"