Ian Prince points out an interesting real-life example of Seaside "session hijacking" (or, if you like, accidental capability transfer). Clearly I'll have to address this in the next release of Seaside.
My inclination is to do this with a "filter", which is how authentication and some kinds of expiration work already. In Seaside 2.5, the implementation of filters has changed quite a bit. During the request processing phase, the request fields get passed down the component tree, with each component extracting the fields that apply to it (that have data for its form elements, for example) and then passing the rest along to its children. The idea is that you wrap a special invisible component around any sensitive parts of the page - in Ian's blog, this might be the sidebar with admin links. These special components perform extra checks before allowing their child components to see the request. A BasicAuthentication filter, for instance, would check to make sure that the appropriate username and password were contained in the request before passing it along, rendering any links or forms in the wrapped component useless if you're not logged in. During the rendering phase, it would perform the same check, and could show a "not authenticated" message in place of the component it is protecting. A hijacking filter would check for a cookie or an IP that it had previously recorded. This allows much finer grained control than a global "disallow hijacked sessions" flag. Of course, if you do want it to apply globally, you just wrap your root component and forget about it.
Note that this is considerably more detail than most framework users would ever care about; for an example of a higher level filter interface, see the usage of #isolate: in this post. I would expect to add something similar like #protect: for hijacking.
Previous Topic
