[Seaside] Session Protector [was Seaside subsets]

[Boris Popov]

Rick,

Session protector stores the remote address of a user and checks it for
every request to prevent most obvious session hijacking (url copying),
especially when not using session cookies. There are a number of
limitations, but not many downsides to using it, so it's a good idea to
have it place working with other measures to secure your applications.

Cheers,

-Boris

-- 
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

boris at deepcovelabs.com

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

> -----Original Message-----
> From: seaside-bounces at lists.squeakfoundation.org [mailto:seaside-
> bounces at lists.squeakfoundation.org] On Behalf Of Rick Flower
> Sent: Wednesday, February 14, 2007 10:24 AM
> To: The Squeak Enterprise Aubergines Server - general discussion.
> Subject: Re: [Seaside] Seaside subsets
> 
> Avi Bryant wrote:
> [ ... ]
> > - We never use the old WAHtmlRenderer code.  Ok, no surprise there,
> > but in case anyone was wondering, it's all Canvas all the way.
> 
> Ditto..
> 
> > - We never use decorations, ever.  No new subclasses of
WADecoration,
> > no #isolate:, no #authenticateWith:during:,etc.  Hasn't come up.
> 
> I've got a WASessionProtector used as part of a decoration and frankly
> I've got no clue what that does for me.. I got it from somewhere
else..
> I might try removing it to see whats missing.. (clueless on that
one)..
> Otherwise I'm really not sure what Decorations get you.
> 
> > - We never use any of the standard dialog or widget components.  For
> > us, anyway, the Canvas tags turn out to be the right level of detail
> > for reuse across apps.  We do plenty of reusing components within
the
> > app, but a generic YesOrNoDialog or WATree doesn't cut it except
when
> > prototyping.
> 
> No widgets here yet and I'm planning on keeping it that way.  I'm
using
> 100% Canvas tags too.
> 
> > - We do use halos, and I'd like to use them more, but they do badly
> > with heavily CSS-styled layouts.  Note that I only use them to see
> > page structure and for view source, I don't use the web-based system
> > browser (that's what the RFB Server is for).
> 
> I use Halo's once in a while as well to view the pretty printed source
> or to configure my app -- I also find that my pages' css can goof up
the
> halo's output, but I can live with that.
> 
> > - We do use the preferences system pretty heavily, with app-specific
> > subclasses of WASystemConfiguration that provide defaults we can
> > override from /config.  But we don't use the baroque multiple
> > inheritance system.
> 
> I'm also using the preferences, though not extensively yet.. It's
> actually pretty cool that I can load my code in from my "Store"
> repository and the WASession is overridden and session timeouts are
> properly set, etc.
> 
> > - We don't use libraries (CSS or Javascript) at all.  We use
> > #updateRoot: and #resourceUrl: heavily to bring in external .css and
> > .js files which the designer controls.
> 
> Ditto.. I was using embedded and #style methods, but have recently
> switched to external files.. Works like a charm!
> 
> > - We use WATask sparingly.  In fact, pretty much the only use is for
> > collecting payment info, which is of course the classic example I
> > always give.
> 
> I don't believe I've got any WATask instances, but I've yet to code up
> my payment mechanism so that may change I suppose.
> 
> > - We certainly do use #call: and #answer:, but much less than you
> > might expect given how much talk there is about continuations.  And
> > the #call: stack rarely gets more than one component deep.  Instead,
> > we're much more likely to conditionally render a child component, or
> > to have a "currentChild" state variable which is constantly modified
> > during navigation.
> 
> None of the #call or #answers either.. I am using a 'currentChild'
sort
> of mechanism that I got from Brian Brown here on the list about a year
> ago.. That went a long way towards working the entire menu system I've
> got now.. I can't thank him enough for his insight, etc.
> 
> > - Except for a handful of those "currentChild" state variables, we
> > don't use WAStateHolder or #registerObjectForBacktracking: at all.
> 
> Ditto..
> 
> > - We do use Scriptaculous, but mostly only the Ajax bits rather than
> > the effects.
> 
> I use SeasideAsync and find it works great for my uses -- I don't need
> the extra features and complexity that Scriptaculous gives -- for now
> anyway..
> 
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside