[prev in list] [next in list] [prev in thread] [next in thread] 

List:       shibboleth-users
Subject:    Re: [Shib-Users] Firefox and "Restore Previous Session"
From:       "Cantor, Scott E." <cantor.2 () osu ! edu>
Date:       2011-06-29 15:19:44
Message-ID: CA30B7E2.EAA2%cantor.2 () osu ! edu
[Download RAW message or body]

On 6/29/11 10:57 AM, "Steve Clay" <steve@mrclay.org> wrote:
>
>Wow, I just verified you and Andrew are correct. I swear this must have
>changed in the past year. Anyway, damn.

Sorry. That's always been the way it worked, it just didn't use to keep
"secure" session cookies. *That* is the bug. And nothing they say to
justify it is persuasive. They are deliberately ignoring the risks and
making the web more unsafe. That's why they're alone in doing this.

>>You can't use naked redirects, it would break the client as soon as an
>> error occurred and leave the user with nothing.
>
>Can you elaborate on this? If the issue is maintaining data w/o the
>cookie, couldn't we use the same auto-submit POST-ing mechanism used
>during auth?

By "naked" I mean anything that takes over the primary frame. You have to
parallelize the logouts (which means third party cookies) or you at least
have to maintain primary UI control at the IdP so that if the single
threaded logout sequence fails, you have a page to get back to. But
realistically, I can't see it working that way, users will be totally lost.

With third party cookies, iframes work pretty well actually. But without
them, you need SOAP, and that breaks most big apps.

I think the best one can do is assume failure (of the logout as a whole),
and decide if one SP + the IdP is "enough" to be worth doing, and
explainable to the user.

-- Scott


[prev in list] [next in list] [prev in thread] [next in thread]