Session management when browser window is cloned

[mikharakiri_nospaum]

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?

 

[Oliver Wong]

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.

- Oliver

 

[Arvind]

Probably not.

Even though i right now dont recall 'how' it was done - but am sure
have seen it done in couple of j2ee applications...sorry not of much
help

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.

As much as i agree with the 'security' implications of trusting the
data from a client - It could be a valid requirement simply to prevent
two browsers from operating on the same data, especially if it is an
edit form....

 

[Oliver Wong]

Even though i right now dont recall 'how' it was done - but am sure
have seen it done in couple of j2ee applications...sorry not of much
help


As much as i agree with the 'security' implications of trusting the
data from a client - It could be a valid requirement simply to prevent
two browsers from operating on the same data, especially if it is an
edit form....

In the case of edit forms, what could be done is to generate a random
number, and place it in the form. Each time you get a submit, check if it
matches what you've got saved on the server side, and then change the random
number. If someone submits twice, you'll get the same number twice, and
you'll accept the first one, but reject the second one, since the second one
doesn't match the server side random number anymore.

I was thinking more along the lines of distinguishing between the user
"cloning" the window (as defined above), versus the user refreshing the
window via F5 for example.

- Oliver

 

[Arvind]

Oliver Wong wrote:

In the case of edit forms, what could be done is to generate a random
number, and place it in the form. Each time you get a submit, check if it
matches what you've got saved on the server side, and then change the random
number. If someone submits twice, you'll get the same number twice, and
you'll accept the first one, but reject the second one, since the second one
doesn't match the server side random number anymore.

I was thinking more along the lines of distinguishing between the user
"cloning" the window (as defined above), versus the user refreshing the
window via F5 for example.

- Oliver

Yes, the solution would help in preventing dual posts - but when you do
a 'new window' wont the 'server' be reached once again ?- in which
case, it would generate a valid counter at the server level and also
embed the same at form level also - right ? (which makes the form work
well unfortunately)

Having said all of this, - still am not sure what the original post's
intention was to prevent cloning of window.

The solution may have to be along the lines of extending
httpsession....

 

[Oliver Wong]

Oliver Wong wrote:


Yes, the solution would help in preventing dual posts - but when you do
a 'new window' wont the 'server' be reached once again ?- in which
case, it would generate a valid counter at the server level and also
embed the same at form level also - right ? (which makes the form work
well unfortunately)

I should have specified that the server only updates its secret number
during a submit, so if the browser tries to get the same page twice without
doing a submit, it'll receive the same secret number twice. When the user
then tries to submit from the first window, it'll get accepted and the
number is updated. When the user then tries to submit from the second
window, the numbers won't match.

- Oliver

 

[Arvind]

Oliver Wong wrote:

I should have specified that the server only updates its secret number
during a submit, so if the browser tries to get the same page twice without
doing a submit, it'll receive the same secret number twice. When the user
then tries to submit from the first window, it'll get accepted and the
number is updated. When the user then tries to submit from the second
window, the numbers won't match.

- Oliver

But generation of the secret number, would have to happen, when the
dispatch to 'edit'-view happens - would it not ? - so if you invoked
/editEmployee - it would generate the secret number, store it at the
server side and have the view embed it into the form...

so if you did a ctrl-n, which would invoke /editEmployee again - it
would generate a new secret number, and embed it in the view yet again
- and it would be a valid case for processing submit...for the new
window - and old window would work like a charm too....

or am i missing something ?

 

[mikharakiri_nospaum]

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:

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.

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.

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).

 

[Arvind]

Oliver Wong wrote:

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.

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.

If you merged, then you are left with the same/single session right ? -
Then i miss your point.

Now the question: how do I manage the session on client side?

It is managed by the cookies on the client side or URL rewriting

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).

That is what the RFC specifcation states - HTTP is a stateless protocol
- after every handshake, the server and client dont know each other.
Session is an ingenious improvement by a handshake mechanism - which
requires a contract between client and server - saying each one will
honour 'identities' of the other... i.e. client will honour the server
identity and send in the token (cookie) and server in turn will honour
the token and issue the 'same' session (identified by the token) to
client .

 

[mikharakiri_nospaum]

Oliver Wong wrote:

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.

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.

If you merged, then you are left with the same/single session right ? -
Then i miss your point.

What do you mean by merge? There are two possibilities to define
session: linear sequence of pages, or tree, but not graph (DAG). My
preference is linear definition, but anyhow neither session concept
allows session merging. One can abandon new session (that is close a
tab, or browser window that hosts a client part of it), which
effectively terminates it on client side.

It is managed by the cookies on the client side or URL rewriting

I don't understand. A client can pass any set of values to the server
-- this is basics of web application programming. The problem is to
identify the session on client side. Does the attribute values set
passed to the server solves this problem automatically? Do cookies?

 

[Oliver Wong]

Oliver Wong wrote:


But generation of the secret number, would have to happen, when the
dispatch to 'edit'-view happens - would it not ? - so if you invoked
/editEmployee - it would generate the secret number, store it at the
server side and have the view embed it into the form...

so if you did a ctrl-n, which would invoke /editEmployee again - it
would generate a new secret number, and embed it in the view yet again
- and it would be a valid case for processing submit...for the new
window - and old window would work like a charm too....

or am i missing something ?

When the user does CTRL-N to create a new window, a new secret number is
stored on the server side, overriding the old secret number. So the new form
will work, but the old one will not.

- Oliver

 

[Oliver Wong]

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