If support for cookies is to be built into turbine. I think the most
logical place to put it would be ParameterParser (PP) as it is just
request data. Already PP provides a central location to grab data from
GET/POST/PATH_INFO. It is a reasonable location for storing Cookie
parameters as well. One potential problem is that right now PATH_INFO
will overwrite GET/POST data. I think GET/POST precendence is set by
the servlet spec, but I could be wrong. The order here may not be as
important as each of these types of data are generated per request, a
cookie however could be interpreted as a default that should or should
not be overridden by other request data. And the should or should not
question might be answered differently in different applications.
I think it is possible for an application to need persistent data
relevant for a specific user and not have it be so sensitive that it
requires explicit user knowledge and a login step. A tv guide app for
example could only request a zip code to set up a user account, the user
then might alter their preferences as far as channels, etc. This
provides the tv guide company with the ability to profile each
user's/family's tv viewing preferences and it is completely anonymous.
People tend to use the same username/passwords over and over. If an
application has little need to require a user to supply a u/p then don't
ask for one.
Jon Stevens wrote:
>
> on 1/29/01 7:04 AM, "Leon Messerschmidt" <[EMAIL PROTECTED]> wrote:
>
> > My idea is mainly to store something like a unique identifier(*not*
> > password) on the client side. On the first hit of a new session the app
> > will check for this id and automatically log the user in if it exists.
> >
> > The users of this app will generally use the system from their own computers
> > only. We also use logging in exclusively for user preferences, and I'd like
> > logging in to be a bit more transparent to the user.
> >
> > What I'm pondering at the moment is whether it would be worthwhile to add
> > some utility class that manages this automatically for you in Turbine. And
> > to what extend - is a general cookie utility good enough or should I go as
> > far as persistent logging in over sessions?
>
> That isn't secure as I could more easily guess your unique ID than I could
> your username/password.
>
> It is *never* a good idea to simplify this stuff for users. It is a fairly
> major security risk to do so and I wouldn't want to encourage people doing
> it in Turbine.
>
> I'm sorry, but I'm going to have to put my foot down on this one. I don't
> mind a class that helps with dealing with HttpSession objects (is it really
> that difficult?), but I do mind a class that helps with making a potentially
> insecure system.
>
> -jon
>
> ------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
> Problems?: [EMAIL PROTECTED]
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
