back to the *point* WAS: Re: [thesite] UEUE v.0.2 Update

[.jeff]

mark,

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> From: Mark Nickel
>
> > take out about the part regarding m.e.o complexities
> > for now. i know we talked about it on the phone, but
> > lets just disregard that 'X factor' :)
>
> Actually, the original question has still gone
> unanswered:  Theoretically, is it possible to create
> an Apache handler in Perl/whatever for m.e.o. that
> would strip all UEUE-based cookies?
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

by strip you mean delete the cookies entirely?  that would have quite
negative effects on persistent logins for those users who visit m.e.o.
sites.  if you're talking about simply suppressing the reporting of the
passed cookies then i believe that will still leave javascript open as a
method of reading the users ueue cookies as javascript asks the browser for
the cookies and doesn't read them from the headers.

><><><><><><><><><><><><><><><><><><><><><><><><><><><><><
> J2EE and .NET are going to rely on server-to-server
> communication to facilitate the authentication...
><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

i really like the sound of this approach.  this serves to remove the
problems associated with multiple redirects, the problems associated with
cookies, the problems with any site that wants to participate having to use
whatever authentication/cookie scheme we put in place, and greatly reduces
the chances of malicious users figuring out our authentication mechanisms
and secret keys (which would still be needed for server-to-server
communication.  we also aren't impaired by cookie number and size limits as
the data would never be transported to the end-user.  at that point we could
effectively create a system that would create a unified session across sites
as opposed to just a unified login.

.jeff

http://evolt.org/
jeff at members.evolt.org
http://members.evolt.org/jeff/