Session data and Control-N issue

[Guest]

Hi

Our application was using Session variables to store business object for our
Web Forms successfully until someone opened a cloned IE window using
Control-N key press.

The cloned window ends up sharing the same business object as the original
window which results in interesting behaviour. For example, if you modify the
business object in one window, it is also effectively modified in the other.

Our users do not want this behaviour.

What is the recommended approach for addressing this issue.

Please note that because of DDA rules, we are not allowed to use JavaScript
on our pages, so I need solutions that do not rely on JavaScript.

Thanks in advance

 

[Jesse Houwing]

Hello Amir,

Hi

Our application was using Session variables to store business object
for our Web Forms successfully until someone opened a cloned IE window
using Control-N key press.

The cloned window ends up sharing the same business object as the
original window which results in interesting behaviour. For example,
if you modify the business object in one window, it is also
effectively modified in the other.

Our users do not want this behaviour.

What is the recommended approach for addressing this issue.

Please note that because of DDA rules, we are not allowed to use
JavaScript on our pages, so I need solutions that do not rely on
JavaScript.

Thanks in advance

You basically have two options

1) Don't use the session only, but a page specific storage, like viewstate
to identify which object to modify. You can still store th eobject in the
session, but use a key stored in the viewstate to retrieve it.

2) switch to cookieless sessions. That way you can start a seperate session
by entering a clean URL. That URL will the automatically get a new SessionID
assigned.

 

[LVP]

Do not use cloned Windows.
Just start a new instance of your Browser.
You can not have the cake and eat it too.

 

[Guest]

Hi Jesse

Thanks for the reply.

1) Our business objects can be quite big so sending them down to the
browser is not option (e.g. ViewState). In fact, we are looking at caching
our objects to disk on our servers to free up memory and just storing a
"pointer" to them in the Session.

2) Even with this approach the user can still press Cntrl+N can't they?
Wouldn't I still get the same problem?

Thanks
Amir

 

[Guest]

Hi LVP

Thanks

I wish I could tell my users not to use cloned windows!

If we can't find a no-JavaScript solution we may well have to explore this
route.

 

[bruce barker]

you need a little more work. you store a request guid on the page. as
pages postback, you save the guid. if a postback happens for an existing
guid, you redirect to a new session.

you can use the same technique with standard sessions. the request guid
is an index into the session.

-- bruce (sqlwork.com)

 

[Jesse Houwing]

Hello Amir,

Hi Jesse

Thanks for the reply.

1) Our business objects can be quite big so sending them down to the
browser is not option (e.g. ViewState). In fact, we are looking at
caching our objects to disk on our servers to free up memory and just
storing a "pointer" to them in the Session.

That wasn't what I meant. I meant, add a hashtable of business objects (or
pointers to business objects) to the session and place the key to that specific
object in the viewstate. Thatw ay you can get the correct object from the
session for each and every page. It even makes it possible to prevent a user
from opening the same object twice (though that will probably not be fool
proof).

2) Even with this approach the user can still press Cntrl+N can't
they? Wouldn't I still get the same problem?

They can, but if they the navigate to teh site (don't copy/paste the link)
it will start a new session.

The best way would be to make sure you check if the object has changes and
notify the user he/she is doing somethign illegal. That solves your problem
altogether. You could use a timestamp to check that. Which would be option
3. The timestamp can then be added to the Viewstate.

And ofcourse you can all three options

Jesse