How in ASP.NET, do you deal with session and multiple tabs?

Question

I have written an application in ASP.net, that is designed to let the user add records to a database. The page is set up that when a user adds a record, the ID number of the newly added record is set in session, the page Response.Redirects to a "Thank you for submitting" page, then redirects back to the original page to allow further edits. Users can also use the Back button on this screen to go back to the original record adding page, which allows them to make edits to the data.

However, I have found that storing the ID in session isn't a terribly good solution, as a user might try to create two documents in different tabs or windows. I have also tried setting the ID in a literal control, but this causes the problem that when the user uses the Back button, the literal control isn't set to the ID, and new records get added instead of one being edited.

Is there any kind of solution for this?

Answer 1

The controls save their state in the ViewState. If you choose to use SessionState instead of ViewState to store the information, then the controls will save their state in the session state and it won't work properly with multiple tabs.

I have not yet found a way to bypass this issue while still using SessionState. Our solution was to use the normal ViewState.

Answer 2

I'd recommend storing your ID in the QueryString. After the record is added, redirect to your "thankyou" page, which then I am guessing contains a link to the edit form which you will generate with the ID in the querystring. When that link is followed, the edit page shouild pull the ID out of the query string in order to load up the correct record to edit.

Your add and edit form can even be the same page, when an ID is provided in the querystring, your form knows to edit that record, otherwise your form adds a new record.

Answer 3

Have you tried adding the ID in the querystring? Then you could read it, and add it to the session as needed (say on a user clicking the back button).

Seems like a lot of problems allowing editing of an object in a page rendered when using the back button. Would it be too much to give them an edit button instead?

Answer 4

I've tried storing the ID in the querystring (which is mostly fine for editing), but the problem with that is when the information is stored in session for when they use the Back button. If the user does the following:

1. User creates a record (1st record), the ID is passed along in the querystring, and temporarily stored in session.
2. User creates another record (2nd record), the ID is passed along in the querystring, temporarily stored in session.
3. User uses the Back button on the first record to go to the page that doesn't have the querystring.

It's probably a far-fetched scenario, but it's one that may happen. The only solution I have is to block the usage of the Back button to go back to the adding page, by using window.history.forward() in JavaScript. But this as a solution is terrible.

Answer 5

My question for you is why are you storing anything in the session to begin with? If you can avoid storing anything in the session, I think you will be better off altogether.

Answer 6

Silly question, why can the user use the back button to edit the data just accepted in a post?

If the edit previously posted data is a common scenario why not just redirect to a page when the data is accepted that lets them edit it. Then if the hit the back button they would be going back to the original "clean" insert/add new data page.

This would give the following flows Add->[Post]->Edit->..... Add->[Post]->Edit->[Back button]->Add->[Post]->Edit->[Post]->Edit....

Answer 7

Having thought about this, does the following sound like a decent solution to the problem I outlined above?

• When first adding a record, store a timestamp of when the add page was accessed in a hidden field.
• This timestamp is passed through session when the user clicks save. Along with the ID.
• If the user opens another tab at the same time and saves, then the new page's timestamp gets passed through session.
• If the user tries to access the add page of first record (using the back button), the system looks up session, and sees if there is a timestamp, and whether it matches the one in the hidden field for that page.
• If it doesn't match, then the user gets a prompt, and told to edit the record properly.

Does this sound reasonable, or too overly complex?