<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>

<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7650.28">
<TITLE>Re: [Seaside] Session (in)security?</TITLE>
</HEAD>
<BODY>
<DIV id=idOWAReplyText32997 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>Right, so we 
<STRONG>are</STRONG> talking about the same thing then. Since not a whole lot of 
modern web apps rely on&nbsp;http auth, wouldn't it make sense to make a cookie 
setting 'true' by default? That's all I was asking for as a newbie seaside user 
who walked right into the trap by having such an obvious flaw pointed out to him 
by one of his peers purely by accident. Its not the kind of mistake I will make 
again, but I'm just trying to look out for those who follow :) That, and the 
WASessionProtector should at least be more obvious, but I'm afraid this'll 
become a documentation discussion in a blink of an eye.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr><FONT face=Arial size=2>Thanks for the feedback 
everyone,</FONT></DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2></FONT>&nbsp;</DIV></DIV>
<DIV id=idSignature17333 dir=ltr>
<DIV><FONT face=Arial color=#000000 
size=2>-Boris<BR><BR>--<BR>+1.604.689.0322<BR>DeepCove Labs Ltd.<BR>4th floor 
595 Howe Street<BR>Vancouver, Canada V6C 
2T5<BR><BR>boris@deepcovelabs.com<BR><BR>CONFIDENTIALITY NOTICE<BR><BR>This 
email is intended only for the persons named in the message<BR>header. Unless 
otherwise indicated, it contains information that is<BR>private and 
confidential. If you have received it in error, please<BR>notify the sender and 
delete the entire message including any<BR>attachments.<BR><BR>Thank 
you.</FONT></DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> seaside-bounces@lists.squeakfoundation.org 
on behalf of Colin Putney<BR><B>Sent:</B> Thu 15/06/2006 5:21 PM<BR><B>To:</B> 
The Squeak Enterprise Aubergines Server - general discussion.<BR><B>Subject:</B> 
Re: [Seaside] Session (in)security?<BR></FONT><BR></DIV>
<DIV><BR>
<P><FONT size=2>On Jun 15, 2006, at 4:37 PM, Boris Popov wrote:<BR><BR>&gt; Oh I 
didn't say there was anything wrong with that, it just seemed&nbsp;<BR>&gt; 
weird<BR>&gt; that one could copy the url from one machine to the other and 
pick&nbsp;<BR>&gt; up an<BR>&gt; exact same session. By the way, password was 
just an example, not&nbsp;<BR>&gt; related to<BR>&gt; the session key issue. 
Obviously our app is password protected as&nbsp;<BR>&gt; well, but<BR>&gt; with 
url copying, all you need is a url of a logged-in user and&nbsp;<BR>&gt; you're 
good<BR>&gt; to go whereas with a cookie you have to try much harder. I settled 
on<BR>&gt; basically using both cookie setting and WASessionProtector, but 
was&nbsp;<BR>&gt; just<BR>&gt; wondering if cookie setting shouldn't be on by 
default for ignorant&nbsp;<BR>&gt; seaside<BR>&gt; beginners like myself, that's 
all :)<BR><BR>I guess I should have been more precise. If you use 
HTTP&nbsp;<BR>authentication, then you'd need both a session key *and* a 
valid&nbsp;<BR>login and password. If you only require login to start a 
session,&nbsp;<BR>then yeah, a session key is enough to hijack the 
session.<BR><BR>Colin<BR>_______________________________________________<BR>Seaside 
mailing list<BR>Seaside@lists.squeakfoundation.org<BR><A 
href="http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside">http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside</A><BR></FONT></P></DIV>

</BODY>
</HTML>