[hunchentoot-devel] Re: session shearing question

[Andrea Chiumenti]

On Jan 16, 2008 6:20 PM, Edi Weitz <edi at agharta.de> wrote:

> On Wed, 16 Jan 2008 10:18:23 +0100, "Andrea Chiumenti" <kiuma72 at gmail.com>
> wrote:
>
> > The behavior in url-rewriting is that, when switching from realm1 to
> > realm2 the session is reset in realm2: this means (setf *session*
> > nil) and (setf (session request) nil).
> >
> > So this will make to create a new session for realm2 but it will
> > maintain the session for realm1.  Navigating inside the same realm
> > maintains the session.
>
> That means that switching realms without cookies will be different
> from switching realms with cookies?  Hmm, not good.

the only possibility is to rewrite/patch the url-rewriter

>
>
> > Please let me know, because I need these info to proceed with my
> > project.
>
> I'm not really convinced yet that this is really a useful addition for
> Hunchentoot.

Sorry, but are you joking ??
Suppose I'm the customer, I buy  a web application from you, this
application is a wonderful e-commerce application, and you use the "user"
session key to store a user principal.
I then "deploy" this web application on my well configured hunchentoot
running on port 4242.
Then I buy from SuperLispCoders L.t.d. another web application that is a
web-log analyzer that has an administrative area.
oops! cl-weblog uses "user" session key too, and for a totally different
need and its structure is different too!!
Please don't tell me to open another port, for policy reasons they are all
closed and my boss told me to use the same hunchentoot instance!!
..... the story continue!

 Also, don't having much time to think about this, are
> you really sure this can't be done with the current session framework
> without the need to patch Hunchentoot or to write your own session
> code?
>
> Anyway, if you need this for your own projects, don't wait for me, but
> rather write code that doesn't depend on a patched Hunchentoot.  I'm
> too busy right now to make any promises about updates or patches.
>
> Edi.
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20080116/0eb6a3fe/attachment.html>