Re: Session management when browser window is cloned
<mikharakiri_nospaum@yahoo.com> wrote in message
news:1146073127.480007.49400@t31g2000cwb.googlegroups.com...
Oliver Wong wrote:
<mikharakiri_nospaum@yahoo.com> wrote in message
news:1145912511.982657.107620@v46g2000cwv.googlegroups.com...
How does the session object behaves when user clones browser window via
Ctrl-N? A simple test shows that the session stays the same. Is there a
way to identify a cloned window session programmatically?
Probably not. Sessions are typically based on cookie or GET urls and
occasionally combined with IP addresses; i.e. data from the client. The
number one rule of web security is never trust data from the client.
I'm keeping the parallel discussion in javascript forum. A brief
synopsys:
You could have avoided this if you had crossposted instead of
multiposted (see http://www.cs.tut.fi/~jkorpela/usenet/xpost.html) On the
other hand, if you DO choose to crosspost to a Java newsgroup and a
JavaScript newsgroup, you should probably say so prominently in your
message, so people don't realize what's going on, and arguments such as "But
that's JavaScript code! The OP is asking about Java!" don't occur.
Let me again state the requirements:
1. If I navigate pages in the same browser window, the session stays
the same. Ditto for navidating with browser "go back/forward one page".
2. If window is cloned, the session identity should change. Ditto for
browser
tabs.
Impossible. There is no way for a server to be able to differentiate
between the client's action of requesting a new page (i.e. going forward)
within the same tab, versus the action of requesting a new page to be
displayed in a new tab, given a sufficiently malicious client.
You will either need to redefine the requirements (e.g. have a weaker
requirements, or forego browsers altogether and use a custom client and
custom protocol), or give up.
The last sentence indicates that I focus on session management, not
window identity [which started JS discussion]. What is the session
definition? Session is some linear sequence of pages that user can
navigate back in forth in time. Any time a web page gets cloned into a
new tab or browser window, a new session is spawned. This is a new
session because the old one is still present and there is no way to
merge the new session into the old one.
That's an interesting definition of "session". It's not the one I would
use in this context, and I suspect it's not the one that JSP uses either
(the reason for which is related to the impossibilities mentioned above).
To me, a session is nothing more than a key-value pair, where the value
can be some composite complex data (the user name, their preferences, their
security access, etc.), and the key is usually a random integer. The client
supplies the key with each request (either via cookies or URL rewrite) to
have the server associate the above mentions values with the given client
for this particular interaction. Immediately after the interaction ends, the
server "forgets" all about the association, which is why the client has to
supply the key each time.
Nothing prevents a client from juggling multiple keys and thus having
multiple sessions going on at the same time with the server. In fact, this
is desirable behaviour if the "apparent" client (as seen by the server
according to the IP address) is actually a node on the network doing NAT and
acting as a proxy for multiple "real" clients.
Now the question: how do I manage the session on client side?
Apparently, without client support server side has no way to manage
sessions. (This strikes me as an extremely odd idea that JSP/Servlet
session concept -- which is about 10 years old concept -- is something
defferent from what I described).
As I said, you can't do what you've described because of limitations of
the HTTP protocol. You'll have to rethink your design.
- Oliver