Reputation: 3352
Usually, HTTP server-side session data storages (for example $_SESSION
in PHP) are implemented using cookies - each client has an unique session ID stored in a cookie. The server receives this cookie and finds the session data using it (as some kind of key or a filename).
This works fine, but sometimes it can cause problems as the cookie (and so the session) is shared across browser tabs.
My question is: Is it possible to implement a server-side data storage which would hold different data for each browser tab? And what is the best way to do it? Without client-side JavaScript.
Example: you have some kind of really complicated form with multiple steps and you want to store the data from previous steps somewhere, before you write everything to the database. You can store the data to the session, but that wouldn't work correctly if someone used the same form in multiple browser tabs - because the session data would be shared. So it would be nice to have a different storage for each tab.
Example #2: you want to allow users to be logged on multiple accounts in the same browser. So you need some kind of "fork" mechanism for the session.
Upvotes: 1
Views: 1415
Reputation: 1764
but that wouldn't work correctly if someone used the same form in multiple browser tabs - because the session data would be shared
And why you don't want to check data in SESSION array (validate) before set or get another pack of data?
But I think, better way - use client-side storage (such as LocalStorage) for setting some data before server-side validating. On High-load project server-side storage for such type of data is not good. If client data can be stored on client - it's should be done.
And what you say, when user reopen second step of form and reenter data? (+ request to server, ++ server load)
Upvotes: 2
Reputation: 33139
It would be best then NOT to rely on Session state but to store data in a temporary storage, server-side, and include a key in a hidden field in your form.
That key gets its value in the first screen of the wizard -- i.e., the first form -- and gets passed on from screen to screen. Then it doesn't matter how many tabs a user has open, each will have its own unique key embedded in the form.
Even if you want to store the form data on the client side you can use this, although it's more complicated. Cookies have names so you can use the unique ID of each form as the cookie name, then store the values in the cookie. Of course you must make sure that the cookie size will not exceed 4K.
Upvotes: 1