>
>
> 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.
Agreed, it seems (to me) very reasonable to add getCookie/setCookie to
ParameterParser or RunData.
> 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.
I tend to agree with this one also. For there to be a security breach,
there has first to be a security requirement, which is not always the case.
Another thing. Is it any more difficult to guess the non-permanent
cookie that is currently used to store sessions than to guess a
permanent cookie used to automate login?
My suggestion: Add the functionality for easy Cookie handling to
ParameterParser/RunData, and then whoever wants to implement a
login Action that will test for cookies can to so, and contribute
it.
>
>
> 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]
>
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
