Dropped session variables tied to SSL pages? Or Redirect?

[Larry Woods]

I am losing Session variables, but only those that are set in the page
previous to a redirect to a secure page.

Anyone seen ANY situation where Session variables just "disappear?"

Note that OTHER session variables are still intact !?!

TIA,

Larry Woods

 

[Ray at]

Session variables will not persist between http and https. If you need them
to, you'll have to create your own "session variable" management system,
such as database stored values. Either that, or put your visitors into
https earlier, if that's an option.

See here: http://www.aspfaq.com/show.asp?id=2157

Ray at work

 

[Larry Woods]

Ray,

I need further clarification. I have another site where I pass around
various session variable value, like UserID, etc. between SSL and non-SSL
pages all the time! The only difference that I can see between the two
sites is the site that works is using the same URL for both SSL and non-SSL
whereas the site that I am having trouble with is using a different URL for
SSL as for the non-SLL pages.

I also commented that some of the Session variables stayed intact. Now I
realize that the ones that were "preserved" were created (recreated!) in
SessionStart in my global.asa. In any case, the other site does perserve
all of my session variables.

Larry Woods

 

[Mark Schupp]

If by "different URL" you mean a path to a different virtual directory or
using a different domain then session variables cannot be passed because the
session cookie can only go to one application. ie:

http://www.mysite.com/app can never share session variables with
https://www.securesite.com/app because the browser will not send the session
cookie to both paths, even it they actually point to the same site.

In the past I have been able to share sessions between http and https when
the paths matched otherwise ( ie: http://www.mysite.com/app and
https://www.mysite.com/app) but this might be considered a security bug that
could be "fixed" in a future browser or IIS version (haven't tried it since
IIS4/IE4).

 

[Larry Woods]

You hit the problem, Mark. The HTTPS site is "safe.xxxxx" and our non-HTTPS
site is www.xxxxx . We had hoped that we would get around the problem
because both "safe" and "www" point to the same URL. But, IIS doesn't look
at IP addresses, I guess.

Could yoiu expand on your statement about the security problem with using
the same URL for both the https and the http. Or, point me to a source of
this info. I have Googled using various keywords but can't find any info on
this.

Thanks.

Larry Woods

 

[Mark Schupp]

I don't know that there is a "security problem" with having sessions shared
between HTTP and HTTPS for the same application path. The point I was making
is that browser designers could very well consider it a problem and not send
cookies set by one to the other.

You could check on the rules for sending cookies to see if this is likely. I
don't know the RFC but it should be on the www.w3c.org site somewhere.

Most responses to this issue recommend the use of a back-end database to tie
the http and https sessions together.

--
Mark Schupp
Head of Development
Integrity eLearning
www.ielearning.com