Re: Sessions/Cookies between sites
From: Janet Fisher (JanetFisher_at_discussions.microsoft.com)
Date: 07/13/04
- Next message: Serge Myrand: "Re: Problem working with parameters (still)"
- Previous message: David: "Re: problems connecting to database from outside."
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 12 Jul 2004 18:21:04 -0700
Hi. I've seen this question a bunch of times, and I was interested in it as well, so I tried to pull together everyone's info.
Session state cannot (and should not) be shared because it would be unsecure to do so. In fact, session data isn't completely secure unless you force an SSL connection. Even then, there are issues with older versions of IIS (5.1 and below) where your session state is lost of you browse from an SSL connection to a non-SSL connection, or vice versa.
Using the application object will persist data in the application collection and make it available to all sessions in an app, but there's no way to restrict access.
So, alternatives to sharing session state seem to be:
- Use a SQL database to persist session variables at the end of each session. This allows for access restrictions. You can use the client's cookie as an identifier if you wish. (from 2 seperate posts)
- Implement your own COM component with shared data. Your apps would call that component.
- Use a message queuing system like MSMQ to save or cache data in a "queue which can either
reside locally or on a dedicated server. Any application can read the queue
once it knows the path to the queue - it typically does
You can store the message in any format from text, to
full blown datasets or custom objects. You can think of the msmq as a robust
caching strategy over a network. It's a good approach because the msmq can
be configured to be fail safe (survive reboots), back up messages, provide
confirmation etc. In addition, msmq can be programmed in a line or two, but
it does require the msmq service to installed and running on the machine." (from "How can I share cached data between web clients?")
- Use the solution in the article at http://www.asp101.com/articles/jayram/sharestate/default.asp. However, one poster said, "you can do what the article suggests without
the massive delete, edit the .webinfo file crap if you set up the parent app
and make the other "apps" subdirs of the parent app (importing, if child
apps already completed). This is really a non-solution for most of us, as
you are essentially killing the child apps and making a single parent app
with all of your applications. You cannot set up the application on a unique
CName, like app1.mydomain.com, as it is tied to the other apps*. Yuck"
- Use remoting.
- Use the Caching Application block.
A good topic on MSDN is "State Management Recommendations" at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon/html/vbconchoosingserverstateoption.asp. It outlines some of the options above.
"Laphan" wrote:
> Thanks Guys
>
> Much appreciated.
>
> Rgds
>
> Robbie
>
> <anonymous@discussions.microsoft.com> wrote in message
> news:b46f01c4377f$ed462cf0$a401280a@phx.gbl...
> From my experience with IIS6 and Windows Server 2003
>
> Session variables are still retained when switching from
> http to https, I never knew it was a bug, I hope Microsoft
> doesn't fix this one.
>
> (Since the session variables are based on a session ID
> cookie, it is really dependent on the client browser
> whether or not the session variables will be retained,
> it's up to the client browser to decide if it should
> include the SessionID cookie in it's https request).
>
> In the case of the original question, his https pages are
> on a different domain then the cookies and session
> variables will definitely not be retained.
>
> But if the user goes back to the http page before his
> session expires then the variables will still be there.
>
> Mendel Nemanov
> Spotlight Design
> >-----Original Message-----
> >Yes, session variables and cookies will not be shared
> between the http and
> >https sites (if the HTTP and HTTPS pages are in the same
> IIS application, it
> >used to be possible to share session state, I don't know
> if that was a bug
> >or a feature. I haven't tried it since IIS 4).
> >
> >Yes, you can pass data back and forth with form elements.
> A more secure
> >approach would be to keep the user data in a database and
> pass only and
> >identifier back and forth.
> >
> >As long as the user returns to one site or another within
> the session
> >timeout period set in IIS their session variables will
> still be available.
> >If cookies are not set to expire or they return before
> the cookie expires
> >then cookies will be available as well.
> >
> >--
> >Mark Schupp
> >Head of Development
> >Integrity eLearning
> >www.ielearning.com
> >
> >
> >"Astra" <info@NoEmail.com> wrote in message
> news:40a0c0df_4@127.0.0.1...
> >> Hi All
> >>
> >> Can I just confirm, is it true that Session Vars and
> Cookies from my main
> >> http site will all be lost when I ask the user to
> transfer over to the
> >> secure (https) side of my site?
> >>
> >> Although the http and https sites are hosted on the
> same ISP they are
> >under
> >> different domains (as well as protocols of course).
> >>
> >> Is it usually the case that I form post/get the
> intrinsic details back and
> >> forth between the http and https so that I can keep
> things on track?
> >>
> >> More importantly, if the user is still in the same
> session and they go to
> >> the https side of the site and then go back to the http
> side (they may
> >want
> >> to check something - because they just do), has all of
> my session var and
> >> cookie data still be lost because of the change of
> sites? I have a
> >feeling
> >> that my cookies will be OK, but my session vars may
> have been lost -
> >> correct?
> >>
> >> Rgds
> >>
> >> Robbie
> >>
> >>
> >
> >
> >.
> >
>
>
>
- Next message: Serge Myrand: "Re: Problem working with parameters (still)"
- Previous message: David: "Re: problems connecting to database from outside."
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
