This SHOULD be an easy question....

[Chad Dokmanovich]

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.

[Spam Catcher]

"Chad Dokmanovich" <ch*************@comcast.netwrote in
news:Xv******************************@comcast.com:

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.

This is how your web browser works (I assume IE) so unless your browser
send some sort of unique identifier... you're SOL.

How about if you load a Java/ActiveX/Javascript applet in the background
which generates a session identifier (i.e. Random Form/URL variable?). Keep
this applet/script running on all pages (IFrame perhaps). When CTRL+N is
hit, I believe the "OnLoad" even should fire - in which case you can triger
the javascript to create a new session id.

You could make the applet even fancier and poll the server to get the login
status... Thus the server could even kick particular windows/sessions out
:-)

[Chad Dokmanovich]

Thanks for the reply.

Interesting idea, it would probably work, I imagine, though I would have to
think that this SHOULDn't be necessary. Also, I am ultimately trying to
write a mobile web app and a downloadable component doesn't sound to me like
it could be applied to any device.

One idea I was considering was to have a hidden form field on each web form
that would store a running sequencial number of the last "post count" from a
unique sessionid. If a user opened a new vrowser, posted, and then returned
to the first and tried to post, the expected sequence of the first would be
off from what was expected and the server would know to start a new session
id and send them to the log on screen.

This interfered more with the user experience but was more of a server based
solution, which is what I was looking for.
What I think IE should do it tell IIS to start a new session number but
copy over all the session info of the spawning session. From there, the
there should be a new session.

There got to be a better way to handle this, I can't accept otherwise.

"Spam Catcher" <sp**********@rogers.comwrote in message
news:Xn*********************************@140.99.99 .130...

"Chad Dokmanovich" <ch*************@comcast.netwrote in
news:Xv******************************@comcast.com:

>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.

This is how your web browser works (I assume IE) so unless your browser
send some sort of unique identifier... you're SOL.

How about if you load a Java/ActiveX/Javascript applet in the background
which generates a session identifier (i.e. Random Form/URL variable?).
Keep
this applet/script running on all pages (IFrame perhaps). When CTRL+N is
hit, I believe the "OnLoad" even should fire - in which case you can
triger
the javascript to create a new session id.

You could make the applet even fancier and poll the server to get the
login
status... Thus the server could even kick particular windows/sessions out
:-)

[Spam Catcher]

"Chad Dokmanovich" <ch*************@comcast.netwrote in
news:js******************************@comcast.com:

Thanks for the reply.

Interesting idea, it would probably work, I imagine, though I would
have to think that this SHOULDn't be necessary. Also, I am ultimately
trying to write a mobile web app and a downloadable component doesn't
sound to me like it could be applied to any device.

Your problem is compounded by two things:

1. There is no defined standard for HTTP sessions - sessions are
provided by the web application framework

2. Multiple windows is a feature of your web browser. Again there is no
standard on how this feature should work. HTTP only defines the
underlying transfer protocol. Thus IE "chose" to keep a session on each
load which is totally legitimate since it doesn't break the HTTP
protocol.

So due to the way HTTP works - we have to live with it's limitations :-(

One idea I was considering was to have a hidden form field on each web
form that would store a running sequencial number of the last "post
count" from a unique sessionid. If a user opened a new vrowser,
posted, and then returned to the first and tried to post, the expected
sequence of the first would be off from what was expected and the
server would know to start a new session id and send them to the log
on screen.

Yes that could work too - but what if a user reloads the form?

What I think IE should do it tell IIS to start a new session number
but copy over all the session info of the spawning session. From
there, the there should be a new session.

Like I said above, HTTP doesn't define these features... so the
characteristic of IE keeping the session while opening a new window is
just how IE works. Another browser could do something totally different.

There got to be a better way to handle this, I can't accept otherwise.

Take a look at the HTTP RFCs, there are no provisions for this sort of
thing.

How about if you fix your web application and don't depend on global
session variables so much? You could fetch the database on each page
load... that'll ensure each page gets rendered correctly. I've seen
several websites where users can have multiple windows opens and still
surf the site OK.