Multiple webapps on one host / Reusing session ids

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Multiple webapps on one host / Reusing session ids

Michael Wyraz
Hi,

when multiple webapps are running on one host (at different ports), each
of them destroys the session id of the other one.
Similar things happens if on a domain and a subdomain are different
webapps (e.g. my.com and shop.my.com).

I have attached a test class that reproduces the problem. If you open a
browser to localhost:8080 a new session is created. when pressing
"reload", the session id is always the same. If then another browser
window to localhost:8081 is opened, this application creates a new
session id. If you switch back to the first window and press "reload"
again, a new session is created there. This has some strange effects if
more than one application is used on one host.

Possible solutions:
1. use different cookie names than JSESSIONID
A simple solution but this breaks the spec.

2. Re-Use a session id provided by the client if there's no other
session with this id
This would solve the problem and should be against the spec. But it
_might_ cause other (security related) problems - i'm not sure with that.


Michael.


import java.io.IOException;
import java.io.PrintWriter;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;

import org.mortbay.http.HttpContext;
import org.mortbay.http.HttpServer;
import org.mortbay.jetty.servlet.ServletHandler;

public class TestJetty
{
    public static void main(String[] args) throws Exception
    {
        // Create the server 1
        startServer(":8080");
        startServer(":8081");
    }

    protected static void startServer(String listen) throws Exception
    {
        HttpServer server=new HttpServer();
        server.addListener(listen);
        HttpContext context = new HttpContext();
        context.setContextPath("/");
        server.addContext(context);

        ServletHandler servlets = new ServletHandler();
        context.addHandler(servlets);
        servlets.addServlet("test","/","TestJetty$TestServlet");
        server.start();
    }

    public static class TestServlet extends HttpServlet
    {
        protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException
        {
            HttpSession session=request.getSession(true);
            String info="Session at "+request.getServerPort()+" = "+session.getId();
            System.err.println("Session at "+request.getServerPort()+" = "+session.getId());
            response.setContentType("text/html");
            PrintWriter out=response.getWriter();
            out.print("<html><body><h1>"+info+"</h1></body></html>");
            out.close();
        }
    }
}
Reply | Threaded
Open this post in threaded view
|

Re: Multiple webapps on one host / Reusing session ids

Anthony Cook-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greetings,

Not sure... is this a question?

Your analysis is correct.  Per the specification:

''HttpSession objects /must be/ scoped at the application (or servlet
context) level.  The _underlying mechanism_, such as the cookie used to
establish the session, _can be the same_ for different contexts, but
*the object referenced...must /never be shared/ between contexts* by the
container.'' Servlet spec. 2.4, SRV 7.1 [emphasis added]

/HttpSession/ objects are tied to the contexts in which they are
created.  This is largely due to the specificity which cookies,
themselves, maintain (including such information as hostname, port, and
~ path, i.e. the URI of the request).  If you need to share client state
information between contexts then another mechanism, like a database,
must be used.  Doing so puts state ("session") management within the
application and does not go against the specification.  Filters and
HttpSessionBindingListeners are good candidates for this.

Regards,

Anthony


Michael Wyraz wrote:
| Hi,
|
| when multiple webapps are running on one host (at different ports), each
| of them destroys the session id of the other one.
| Similar things happens if on a domain and a subdomain are different
| webapps (e.g. my.com and shop.my.com).
|
| I have attached a test class that reproduces the problem. If you open a
| browser to localhost:8080 a new session is created. when pressing
| "reload", the session id is always the same. If then another browser
| window to localhost:8081 is opened, this application creates a new
| session id. If you switch back to the first window and press "reload"
| again, a new session is created there. This has some strange effects if
| more than one application is used on one host.
|
| Possible solutions:
| 1. use different cookie names than JSESSIONID
| A simple solution but this breaks the spec.
|
| 2. Re-Use a session id provided by the client if there's no other
| session with this id
| This would solve the problem and should be against the spec. But it
| _might_ cause other (security related) problems - i'm not sure with that.
|
|
| Michael.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCy/B+8KND+nha8AoRAgepAJ9rBV5qJ+3uZ7orWd/TSEgTAeK15wCeJTKd
SX7K3ogcR+Ji/5JnryJODJE=
=wk6P
-----END PGP SIGNATURE-----


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Multiple webapps on one host / Reusing session ids

Michael Wyraz
Hi,

I don't want to share session information over multiple webapps. I speak
of fully independent webapps
which are running on the same host on different ports. Currently when i
log on to one webapp in
one window and then log on to the other in a different browser window,
the session cookie of the
first webapp gets overwritten. The result is that i loose my session in
the first webapp and when i re-login
there, i loose my session in the other webapp.

I think, when the client provides a session cookie which is not already
assigned to a running session in the
current context, this session cookie should be re-used instead of
creating a new.

So maybe the implementation could be changed to avoid this problem
(maybe as a runtime option). And to
discuss this, i joined this discussion mailing list ;-). So my post is
not really a question but might be the start of a
discussion about this...

Michael.

>
> Greetings,
>
> Not sure... is this a question?
>
> Your analysis is correct.  Per the specification:
>
> ''HttpSession objects /must be/ scoped at the application (or servlet
> context) level.  The _underlying mechanism_, such as the cookie used to
> establish the session, _can be the same_ for different contexts, but
> *the object referenced...must /never be shared/ between contexts* by the
> container.'' Servlet spec. 2.4, SRV 7.1 [emphasis added]
>
> /HttpSession/ objects are tied to the contexts in which they are
> created.  This is largely due to the specificity which cookies,
> themselves, maintain (including such information as hostname, port, and
> ~ path, i.e. the URI of the request).  If you need to share client state
> information between contexts then another mechanism, like a database,
> must be used.  Doing so puts state ("session") management within the
> application and does not go against the specification.  Filters and
> HttpSessionBindingListeners are good candidates for this.
>
> Regards,
>
> Anthony
>
>
> Michael Wyraz wrote:
> | Hi,
> |
> | when multiple webapps are running on one host (at different ports),
> each
> | of them destroys the session id of the other one.
> | Similar things happens if on a domain and a subdomain are different
> | webapps (e.g. my.com and shop.my.com).
> |
> | I have attached a test class that reproduces the problem. If you open a
> | browser to localhost:8080 a new session is created. when pressing
> | "reload", the session id is always the same. If then another browser
> | window to localhost:8081 is opened, this application creates a new
> | session id. If you switch back to the first window and press "reload"
> | again, a new session is created there. This has some strange effects if
> | more than one application is used on one host.
> |
> | Possible solutions:
> | 1. use different cookie names than JSESSIONID
> | A simple solution but this breaks the spec.
> |
> | 2. Re-Use a session id provided by the client if there's no other
> | session with this id
> | This would solve the problem and should be against the spec. But it
> | _might_ cause other (security related) problems - i'm not sure with
> that.
> |
> |
> | Michael.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.0 (GNU/Linux)
>
> iD8DBQFCy/B+8KND+nha8AoRAgepAJ9rBV5qJ+3uZ7orWd/TSEgTAeK15wCeJTKd
> SX7K3ogcR+Ji/5JnryJODJE=
> =wk6P
> -----END PGP SIGNATURE-----
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> jetty-discuss mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jetty-discuss




-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Multiple webapps on one host / Reusing session ids

Anthony Cook-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

OK, now I get the issue. ':)

Check the session cookie's binding attributes in your browser's cookie
manager.  It /may be/ that Jetty is not providing sufficiently unique
'path' information to keep one context's session cookie from overwriting
another (though, I remain somewhat skeptical on this point, see below).
~ If this is the case then the problem is indeed with Jetty.

If not the case then the problem is likely with your web browser (which
is??), or its cookie management configuration.  For example, have you
tried a different browser, or tried deploying your applications in a
different container (Tomcat, Resin, etc.) and using the same browser?

Changing your application to use URL rewriting explicitly, instead of
implicitly relying on cookies, is another possibility.

Michael Wyraz wrote:
| I think, when the client provides a session cookie which is not already
| assigned to a running session in the
| current context, this session cookie should be re-used instead of
| creating a new.
|

Problem is, its a bigger issue for the container than it is for the
client and the container can not always rely on what the client's notion
of its session is.  In the case of a server crash, for example, the
presented session ID will no longer be valid.  In any case, I fail to
see how this would resolve your issue since the cookie must still be
associated with certain contextual information and this will not have
changed from either the browser's or container's perspectives and it is
likely this "contextual information" that is somehow behind the fault...

While the spec. defines what the container must do to support sessions
- -- such as providing a unique ID to each one -- it cares little for
/how/ the container does it.  So, "yes", from a purely technical view
point the container /might/ be able to reuse the prior session ID, as
opposed to generating a new one.  However, this can also create internal
management issues which can needlessly impact the container's
reliability and performance.  It's just as easy, and quick, to generate
a new session ID, for a new session instance, and doing so also avoids
unnecessary overhead in trying to "reuse" sessions.

After six generations of servlet specification refinement and production
implementation, I, for one, am confident in the spec's recognition and
accounting of these types of issues. :)  Afterall, it is rather
pointless to define support for separate contexts if they are, in fact,
not handled distinctly by the container.  After five generations of
Jetty, I would find it "odd", to say the least, if Jetty does not
properly handle separate running contexts "distinctly"... Of course,
"bugs" can be introduced with each new version and so perhaps you are
encountering one.  Though, my money is still on the browser. :)

| So maybe the implementation could be changed to avoid this problem
| (maybe as a runtime option). And to
|

/If/ it is, in fact, the [container] implementation that is at fault,
then the implementation certainly needs to be fixed.  Beyond that, I can
see no reason to change the implementation. ;)

| discuss this, i joined this discussion mailing list ;-). So my post is
| not really a question but might be the start of a
| discussion about this...
|

Welcome aboard. :)

| Michael.
|

Regards,

Anthony
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCzDW48KND+nha8AoRAoW4AJ4+kPJ2CFgFpasNwadEtIme6B7CggCfThxo
EbfEgHc3t75uNdwYX0knKYY=
=6wnI
-----END PGP SIGNATURE-----


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Multiple webapps on one host / Reusing session ids

Michael Wyraz
Hi,

this is an issue with some containers and some browsers (i tried tomcat
and jetty
with both, internet explorer and firefox). But my use case (where i
found that
strange behaviour) is a bit uncommon:
I have an application at mydomain.com. A restricted area (which is in
fact a completely
different application) is on subdomain.mydomain.com. When i log in to
one of this applications,
_sometimes_ i can use the other app without problems. But in most cases
it won't work
(this is caused by the order the cookies are set, because one of both
domains recieved
both cookies). At least with firefox i can always reproduce the problem
when i use
two different ports on the same host.

So it's difficult to say wheather it's a container or a browser problem.
It occurs on both
containers and on both browsers. I have read that resign allows to
change the cookie
name to workaround the problem. I also contacted the tomcat people but i
have no reponse
from them up to now.

Michael.

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> OK, now I get the issue. ':)
>
> Check the session cookie's binding attributes in your browser's cookie
> manager.  It /may be/ that Jetty is not providing sufficiently unique
> 'path' information to keep one context's session cookie from overwriting
> another (though, I remain somewhat skeptical on this point, see below).
> ~ If this is the case then the problem is indeed with Jetty.
>
> If not the case then the problem is likely with your web browser (which
> is??), or its cookie management configuration.  For example, have you
> tried a different browser, or tried deploying your applications in a
> different container (Tomcat, Resin, etc.) and using the same browser?
>
> Changing your application to use URL rewriting explicitly, instead of
> implicitly relying on cookies, is another possibility.
>
> Michael Wyraz wrote:
> | I think, when the client provides a session cookie which is not already
> | assigned to a running session in the
> | current context, this session cookie should be re-used instead of
> | creating a new.
> |
>
> Problem is, its a bigger issue for the container than it is for the
> client and the container can not always rely on what the client's notion
> of its session is.  In the case of a server crash, for example, the
> presented session ID will no longer be valid.  In any case, I fail to
> see how this would resolve your issue since the cookie must still be
> associated with certain contextual information and this will not have
> changed from either the browser's or container's perspectives and it is
> likely this "contextual information" that is somehow behind the fault...
>
> While the spec. defines what the container must do to support sessions
> - -- such as providing a unique ID to each one -- it cares little for
> /how/ the container does it.  So, "yes", from a purely technical view
> point the container /might/ be able to reuse the prior session ID, as
> opposed to generating a new one.  However, this can also create internal
> management issues which can needlessly impact the container's
> reliability and performance.  It's just as easy, and quick, to generate
> a new session ID, for a new session instance, and doing so also avoids
> unnecessary overhead in trying to "reuse" sessions.
>
> After six generations of servlet specification refinement and production
> implementation, I, for one, am confident in the spec's recognition and
> accounting of these types of issues. :)  Afterall, it is rather
> pointless to define support for separate contexts if they are, in fact,
> not handled distinctly by the container.  After five generations of
> Jetty, I would find it "odd", to say the least, if Jetty does not
> properly handle separate running contexts "distinctly"... Of course,
> "bugs" can be introduced with each new version and so perhaps you are
> encountering one.  Though, my money is still on the browser. :)
>
> | So maybe the implementation could be changed to avoid this problem
> | (maybe as a runtime option). And to
> |
>
> /If/ it is, in fact, the [container] implementation that is at fault,
> then the implementation certainly needs to be fixed.  Beyond that, I can
> see no reason to change the implementation. ;)
>
> | discuss this, i joined this discussion mailing list ;-). So my post is
> | not really a question but might be the start of a
> | discussion about this...
> |
>
> Welcome aboard. :)
>
> | Michael.
> |
>
> Regards,
>
> Anthony
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.0 (GNU/Linux)
>
> iD8DBQFCzDW48KND+nha8AoRAoW4AJ4+kPJ2CFgFpasNwadEtIme6B7CggCfThxo
> EbfEgHc3t75uNdwYX0knKYY=
> =6wnI
> -----END PGP SIGNATURE-----
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> jetty-discuss mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jetty-discuss




-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Multiple webapps on one host / Reusing session ids

Anthony Cook-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

OK.  Unfortunately, because of the way host name matching is specified
in "HTTP State Management", where a subdomain 'Y' is part of the FQDN
'X', or 'X' is catalogued open-prefixed ('.X'), both may be treated as
referring to the same request host (er, "server") by the client.
There's not a lot that can be done about it in either client or server
until the specification changes to mandate an explicit host match.

However, in these cases the cookie's /path/ attribute should take
precedence, though the attribute is optional.  Ideally, the container
should therefore use the context as the path attribute to further
differentiate one cookie from another.  Yet, this too is no guarantee
since the same "context" may be running on the different "[sub-]hosts"
or be configured to run on top of the server's root context.  Either
case just resurfaces the client-side handling issue.  Furthermore, as
reminded by the spec.:

''Due to the fact that cookies...are typically controlled by the Web
browser /process/ and are not associated with any particular window of
the browser,....the Developer should /always assume/ that all windows of
a client are /associated with the same session/.'' -- Servlet 2.4, SRV
7.7.3 [emphasis added]

I would also add 'Deployer' and 'Administrator' along with Developer in
the above section.  By running the different applications within the
same base 'host name' your application is left open to a wide variety of
"gotchas" that might otherwise be resolved given a different State
Management spec.

Yet, we have what's been given to us, no?  So, without turning to
implementatation-specific "options" (which then needlessly bind the
application to that implementation), we are left with having to work
around these issues beginning with application design.  Some
possibilities include:

* Change the applications to use URL rewriting for session persistence;

* Use "virtual hosts" to distinctly separate the applications and bypass
the issue entirely;

* Sub-context the "restricted" application onto the "open" one and use
security-constraints to keep it "restricted"; distinct session
attributes can be used to track their relevant states;

* As the previous but use "programmatic security" (authorization) to
further control access within the "restricted" application.

Regards,

Anthony


Michael Wyraz wrote:
| Hi,
|
| this is an issue with some containers and some browsers (i tried tomcat
| and jetty
| with both, internet explorer and firefox). But my use case (where i
| found that
| strange behaviour) is a bit uncommon:
| I have an application at mydomain.com. A restricted area (which is in
| fact a completely
| different application) is on subdomain.mydomain.com. When i log in to
| one of this applications,
| _sometimes_ i can use the other app without problems. But in most cases
| it won't work
| (this is caused by the order the cookies are set, because one of both
| domains recieved
| both cookies). At least with firefox i can always reproduce the problem
| when i use
| two different ports on the same host.
|
| So it's difficult to say wheather it's a container or a browser problem.
| It occurs on both
| containers and on both browsers. I have read that resign allows to
| change the cookie
| name to workaround the problem. I also contacted the tomcat people but i
| have no reponse
| from them up to now.
|
| Michael.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCzFWl8KND+nha8AoRAkn5AJ96ma7mISIt2VqYdiJ8aeysLQebBwCdEf4U
s1c26vHTHjdP904qwh62m74=
=AroW
-----END PGP SIGNATURE-----


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Multiple webapps on one host / Reusing session ids

Greg Wilkins-5

Guys,

Jetty is very configurable with regards to this behaviour.    So firstly
it would be good to see some requests dumps of the "situation" you
are describing.  That way we can see the cookies being set and the paths
they are being set with.

By default jetty should set the context path as the path on the session cookies.
However you can set the context param org.mortbay.jetty.servlet.SessionPath
to control the session path.

But jetty also has a mode of supporting crossContextSessionIDs, in which
case the session ID is shared between contexts and the path is set to /.
The contexts have different sessions (with different contents) but the
same session ID.

The catch is that invalidation of one session will invalidate all sessions
with that ID.  So it sounds like you may be running in this mode.

Do you configure your session manager?  If you do, do you set crossContextSessions
to be true? (or the deprecated useRequestedId)

regards




-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Multiple webapps on one host / Reusing session ids

jian chen
Hi,

Just glanced through the related emails. Though this might be helpful below.

What we are doing is, the same HttpSession object is used by multiple
web apps all running on the same host and port.

We use part of the URL to map the applications.

For example, to create a new session,

1) for http://localhost:8080/app1, we have
session.setAttribute("app1", new CustomSessionClass1());

2) for http://localhost:8080/app2, we have
session.setAttribute("app2", new CustomSessionClass2());

So, when a request comes in, you can retrieve the CustomSessionClass
object according to different application from the HttpSession object.

This way, no matter how many browser session opens, they all run differently.

Bottom line is, HttpSession is used as a hashtable for storing the
actual custom session objects rather than storing the session data
themselves.

Does this make sense to your problem?

Cheers,

Jian

On 7/7/05, Greg Wilkins <[hidden email]> wrote:

>
> Guys,
>
> Jetty is very configurable with regards to this behaviour.    So firstly
> it would be good to see some requests dumps of the "situation" you
> are describing.  That way we can see the cookies being set and the paths
> they are being set with.
>
> By default jetty should set the context path as the path on the session cookies.
> However you can set the context param org.mortbay.jetty.servlet.SessionPath
> to control the session path.
>
> But jetty also has a mode of supporting crossContextSessionIDs, in which
> case the session ID is shared between contexts and the path is set to /.
> The contexts have different sessions (with different contents) but the
> same session ID.
>
> The catch is that invalidation of one session will invalidate all sessions
> with that ID.  So it sounds like you may be running in this mode.
>
> Do you configure your session manager?  If you do, do you set crossContextSessions
> to be true? (or the deprecated useRequestedId)
>
> regards
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
> core and dual graphics technology at this free one hour event hosted by HP,
> AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
> _______________________________________________
> jetty-discuss mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jetty-discuss
>


-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Multiple webapps on one host / Reusing session ids

Philipp Meier
Am Donnerstag, den 07.07.2005, 21:07 -0700 schrieb jian chen:


> What we are doing is, the same HttpSession object is used by multiple
> web apps all running on the same host and port.
>
> We use part of the URL to map the applications.
>
> For example, to create a new session,
>
> 1) for http://localhost:8080/app1, we have
> session.setAttribute("app1", new CustomSessionClass1());
>
> 2) for http://localhost:8080/app2, we have
> session.setAttribute("app2", new CustomSessionClass2());
>
> So, when a request comes in, you can retrieve the CustomSessionClass
> object according to different application from the HttpSession object.
>
> This way, no matter how many browser session opens, they all run differently.
>
> Bottom line is, HttpSession is used as a hashtable for storing the
> actual custom session objects rather than storing the session data
> themselves.

This way you will loose the notification on the lifecycle of the
individual attributes and your CustomSessionClass must be serializable
to enable clustering. I'd rather suggest a session wrapper which enables
namespaces in the session:

nsSession = new NsSession(session);
nsSession.setAttribute("app1", "session key", value)
value = nsSession.getAttribute("app1", "session key")

NsSession maps these request to the session key "app1.session key". With
proper escaping of "." to ".." this is a clean solution for namespacing
the session.

-billy.

--
3-2-1 Verkaufsagentur ***       Wir verkaufen für Sie!         ***
Herrmann-Köhl-Str. 5  *** Petrusplatz neben der Marienapotheke ***
89231 Neu-Ulm         ***  http://www.321-verkaufsagentur.de/  ***




-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Multiple webapps on one host / Reusing session ids

Michael Wyraz
In reply to this post by Greg Wilkins-5
Hi Greg,

great, this "crossContextSessionIDs" setting sounds exactly as what i
need. Will this also work across
Jetty instances?

Next week i'll be back in my company and then i'm going to do some tests
with this.

Thank you,

Michael.

>Guys,
>
>Jetty is very configurable with regards to this behaviour.    So firstly
>it would be good to see some requests dumps of the "situation" you
>are describing.  That way we can see the cookies being set and the paths
>they are being set with.
>
>By default jetty should set the context path as the path on the session cookies.
>However you can set the context param org.mortbay.jetty.servlet.SessionPath
>to control the session path.
>
>But jetty also has a mode of supporting crossContextSessionIDs, in which
>case the session ID is shared between contexts and the path is set to /.
>The contexts have different sessions (with different contents) but the
>same session ID.
>
>The catch is that invalidation of one session will invalidate all sessions
>with that ID.  So it sounds like you may be running in this mode.
>
>Do you configure your session manager?  If you do, do you set crossContextSessions
>to be true? (or the deprecated useRequestedId)
>
>regards
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
>July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
>core and dual graphics technology at this free one hour event hosted by HP,
>AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
>_______________________________________________
>jetty-discuss mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/jetty-discuss
>  
>



-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss