Re: [cgiapp] CAP::Authentication & cookies

["Cees Hek" <suppressed>]

On 3/27/06, Ron Savage <suppressed> wrote:
> On Mon, 27 Mar 2006 15:08:08 -0500, Cees Hek wrote:
>
> Hi Cees
>
> > The systems needs to be able to identify the user at the other end
> > in one way or another.  That is most often done with cookies, and
> > in the case of the Authen plugin, it offers the Session based or
> > Cookie based way of tracking who the users is.  Unfortunately for
> > you, as you have found out. both default to using cookies to track
> > who the user is.
>
> Why is that?
>
> Is this documented?
>
> Is it a defect in the design, even if deliberate?

I mentioned that by default it works that way.  In other words, it
will only try to keep your session ID persistent using cookies.  If
you want to use another technique, then you have to do that side of it
manually (ie filling in IDs into every URL and form).  The Authen
plugin when using the session store really only expects there to be a
$self->session method that returns a valid CGI::Session object. 
Beyond that it just stores info there, and expects it to be there on
the next request.

> > So really your only way out is to use the kludge method of passing
>
> I object to the word kludge! Aren't we agreed that TMTOWTDI?

Just because there is more than one way, doesn't mean that some of
those ways are not kludges ;-)

> Surely it's personal preference, in that there's no one way which is best in
> every circumstance.

Sure, it is personal preference, and if the requirements came down
from the client that cookies were optional, but sessions were
required, then I would probably use the URL method (or some
mod_rewrite hacks).

> > around the session ID in forms and URLs (or do some funky
> > PATH_INFO/mod_rewrite stuff, or even switch to good ol' Basic
> > Authentication that your web server provides).  Or do what I
> > usually do and just ignore people that turn off cookies.  Why cater
> > to a misguided minority that use a sledgehammer where a screw
> > driver would suffice...
>
> As Steve Gibson says: It's MY computer! I.e.: Let the user do what they want.

Nothing can be forced on the user.  The user always has the choice to
decline cookies.  Or for that matter they can decline to view images,
and decline to apply your CSS styles.  But if they come to me and
complain that things aren't working, I will tell them to turn cookies
on, and use my stylesheet instead of their own...  At that point they
still have to option accept or decline.

> But why choose a method with requires user intervention in the first place?

Using cookies does not require user intervention.  It works
seemlessly.  The whole purpose of cookies is to provide a means of
maintaining state in a stateless environment.  So why not use it?  It
only requires user intervention if the user chooses to be notified
when cookies are set.  But that is a choice the user makes.

I would posit that using URL based sessions is more of a hassle for
the end user since there is no way to maintain a session across a
browser restart short of creating a bookmark.  Also, as a developer
you limit yourself to only using dynamic pages, since you can not send
a user to a static page or they will loose their session (the static
page will not have the sessionID embeded in it's links).

> > It's possible that I might ruffle some feathers with that one as I
> > am sure there are some people on the list that disable cookies by
> > default.  If you do that, make sure you have the tools available to
> > selectively turn on cookies where it makes sense.
>
> Well, I never use cookies in my apps, so I don't care what the user chooses to
> do by way of allowing/disallowing them.

To me that is just too much work, for too little gain.  But that
doesn't mean that I think it is wrong not to use cookies. For me it
just seems like a waste of time in most cases.  But as you say,
TMTOWTDI

Cheers,

Cees

---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed