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

mikharakiri_nosp...@yahoo.com wrote:
<snip>

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

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

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 .

--
Arvind

   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.

   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.

   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.

   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