[prev in list] [next in list] [prev in thread] [next in thread]
List: barracuda
Subject: Barracuda: cookies and logins
From: barracuda () enhydra ! org (Diez B ! Roggisch)
Date: 2001-11-27 11:34:33
[Download RAW message or body]
Hi,
although I don't see the need for this so much - we _can_ set cookies in a
render-event - but my 2 cents on Jacob:
This morning I thought about that problem - and of course a responsible
programmer will encrypt the password. BUT making this a default
in the CookieHandler will no allow one to use the encryption he wants to.
Maybe UNIX crypt, or MySQL or.....
At least, we can't force bad coders to do it the right way - otherwise I
wouldn't see any JSP-knowledge-requirements in job-ads :)
Diez
-----Original Message-----
From: barracuda-admin@enhydra.org [mailto:barracuda-admin@enhydra.org]On
Behalf Of Jacob kjome
Sent: Saturday, November 24, 2001 5:11 AM
To: barracuda@enhydra.org
Subject: RE: Barracuda: cookies and logins
Hi Christian,
Yes, absolutely! I had only been using cookies for sessions, so I was
just letting the servlet engine take care of all that. However, I've
definitely had sites where I had to implement automatic logins. Actually,
most of the larger e-commerce sites have this option, so there is definitely
precedent for a CookieServices class. Also, given the security issues in an
auto-login feature, the CookieServices class might want to implement some
encryption on the cookie string itself. Marking a cookie "secure" only
ensures that it is only sent back over an ssl connection. However, the data
in the cookie can be read on the user's computer by someone snooping around.
However, maybe that is the responsibility of the developer and not a generic
CookieServices class. Just wanted to bring up the issue in case it made
sense for the CookieServices class to implement some sort of
encryption/security feature.
BTW, I have an example of using an md5 algorithm on both client
(javascript) and server side (java, of course) that could be useful here.
I'd have to ask the guy who created it if he would allow it to be used for
Barracuda first. It could be very useful, though.
Jake
I hadn't been using cookies much except for
[Attachment #3 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=us-ascii" http-equiv=Content-Type>
<META content="MSHTML 5.00.2920.0" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=867042911-27112001>Hi,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=867042911-27112001></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=867042911-27112001>although I don't see the need for this so much - we
_can_ set cookies in a render-event - but my 2 cents on
Jacob:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=867042911-27112001></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=867042911-27112001>This
morning I thought about that problem - and of course a responsible programmer
will encrypt the password. BUT making this a default</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=867042911-27112001>in the
CookieHandler will no allow one to use the encryption he wants to. Maybe UNIX
crypt, or MySQL or.....</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=867042911-27112001></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=867042911-27112001>At
least, we can't force bad coders to do it the right way - otherwise I wouldn't
see any JSP-knowledge-requirements in job-ads :)</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=867042911-27112001></SPAN></FONT> </DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN
class=867042911-27112001>Diez</SPAN></FONT></DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
<DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> barracuda-admin@enhydra.org
[mailto:barracuda-admin@enhydra.org]<B>On Behalf Of </B>Jacob
kjome<BR><B>Sent:</B> Saturday, November 24, 2001 5:11 AM<BR><B>To:</B>
barracuda@enhydra.org<BR><B>Subject:</B> RE: Barracuda: cookies and
logins<BR><BR></DIV></FONT><FONT size=3>Hi Christian,<BR><BR>Yes,
absolutely! I had only been using cookies for sessions, so I was just
letting the servlet engine take care of all that. However, I've
definitely had sites where I had to implement automatic logins.
Actually, most of the larger e-commerce sites have this option, so there is
definitely precedent for a CookieServices class. Also, given the
security issues in an auto-login feature, the CookieServices class might want
to implement some encryption on the cookie string itself. Marking a
cookie "secure" only ensures that it is only sent back over an ssl
connection. However, the data in the cookie can be read on the user's
computer by someone snooping around. However, maybe that is the
responsibility of the developer and not a generic CookieServices class.
Just wanted to bring up the issue in case it made sense for the CookieServices
class to implement some sort of encryption/security feature.<BR><BR>BTW, I
have an example of using an md5 algorithm on both client (javascript) and
server side (java, of course) that could be useful here. I'd have to ask
the guy who created it if he would allow it to be used for Barracuda
first. It could be very useful, though.<BR><BR><BR>Jake<BR><BR>I hadn't
been using cookies much except for <BR><BR></FONT></BLOCKQUOTE></BODY></HTML>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic