This SHOULD be an easy question....

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance



As someone who's had a "fair" amount of web development experience, I
shocked that I can't answer this question myself:

Q: How does one maintain state and pass data across web pages and do so in a
secured manner?

Before you answer, let me assure you that I familiar with the normal methods

1- Passing data in the Query String
2 - Hidden form fields
3- Session Variables
4 - Cookies

option 1
For option 1 to be secure, I would need to encrypt the query string before
sending. This is OK, but the query string is limited and I have too much
state data that I need to store. I could store this data in a database, but
how would I identify the state data at the BROWSER INSTANCE level? Note that
if one browser window spawns a nother, they share the same session ID, so I
can't use this as a key to the data in the database. This is really my main
problem. I need to maintain separate state info for each browser regardless
of how the browser was instantiated.

Option 2-
Yeah, that would work, but it is clumbsy to have hidden fields and it isn't
practical for storing a lot of data. It also is not secure since you can
view it using "View Source". I could encrypt it. Yuck.

Option 3-
Same problem as 1, I think. If you spawn a new browser using <Control N>,
the new browser window is sharing the session state with the old. What I
think the browser should do is tell IIS that a new browser window was
created so IIS would COPY the session data of the current session and create
a new session with the data from the old session as a starting point, but
from that point on, they would be separate sessions.

4-Insecure, and could be disabled and may not be supported on mobile
devices, which I need to target.

The major issue is that I need to be able to unqiue identify a BROWSER
instance. I don't know how to handle when two browser windows share the same
session data. This was a surprise when I realize that this is what happens.
I suspect too that it is also the soure of many potential bugs for existing
web apps.

Your thoughts would be appreciated.






.



Relevant Pages

  • Re: Sessions and clients
    ... This entrance page gives out a random session URL. ... you get the login page. ... user gets a *different* username. ... closes the browser, or the browser, computer, or Internet connection ...
    (comp.lang.php)
  • Re: ASP sessionstate
    ... ASP doesn't know or care what browser it ... ticket number given when the first item is added to the cart. ... How can a Response.Write write to the server screen? ... :> delete the cart file and set the session ...
    (microsoft.public.inetserver.asp.general)
  • "Compaq Web Agent" management session can be re-used without the need to perform authentic
    ... destructive actions (as server reboot). ... Compaq Web Agent Service 6.0.0.0 using Compaq HTTP Server 5.1.0 on ... servers via a secured HTTP session from a browser client, ... via a legitimate authenticated SSL session - if he closes the session by ...
    (Bugtraq)
  • Re: Problem with a session
    ... Your first posting was a bit vague, but now I understand your problem. ... the POSTDATA and sets againg the session variable to true and anyone ... This IS a real problem, and you cannot 100% solve it. ... try to tell the browser NOT to chache it. ...
    (comp.lang.php)
  • Re: Attempt to de-mystify AJAX
    ... >>maintaining a session via URL is not a problem. ... >> around cookies and JS, but it seems to be tough. ... >> as needed back to the server. ... but as I mentioned before - a non-dynamic request by the browser can ...
    (comp.databases.pick)