Losing Session variables

[GFuller]

- We have 2 aspx pages in a .NET project. The first sets
a session variable and has a button that when clicked
performs a 'redirect' to the second page which then reads
the session variable.

Problem: This always works fine on the localserver and
through the IDE. But when the application is put onto a
www website, the following occurs;
- If you browse to the site using the IP address, session
variables work fine
- If you browse to the site using the Web Site Domain Name
(ie [url]http://www.tmcontrol.com[/url]) session variables are NOT
retrieved properly. Further investigation included
outputting the value of Session.SessionID. In the cases
where session variables were working (IP browsing) the
SessionID matches for both pages. In the case of failure
(name browsing), the SessionIDs are different indicating a
new session.

We tried to workaround this issue by setting SessionState
cookieless to "true" in web.config and while this seems to
correct the session problem, it causes problems with Form
data being returned from Verisign in later processing.

[Alvin Bruney]

you may want to use Server.Transfer('page',true) instead of redirect to
ensure that the session state is preserved.

"GFuller" <greg.fuller@L-3com.com> wrote in message
news:018a01c35b74$f19d2ed0$a301280a@phx.gbl...

> - We have 2 aspx pages in a .NET project. The first sets
> a session variable and has a button that when clicked
> performs a 'redirect' to the second page which then reads
> the session variable.
>
> Problem: This always works fine on the localserver and
> through the IDE. But when the application is put onto a
> www website, the following occurs;
> - If you browse to the site using the IP address, session
> variables work fine
> - If you browse to the site using the Web Site Domain Name
> (ie [url]http://www.tmcontrol.com[/url]) session variables are NOT
> retrieved properly. Further investigation included
> outputting the value of Session.SessionID. In the cases
> where session variables were working (IP browsing) the
> SessionID matches for both pages. In the case of failure
> (name browsing), the SessionIDs are different indicating a
> new session.
>
> We tried to workaround this issue by setting SessionState
> cookieless to "true" in web.config and while this seems to
> correct the session problem, it causes problems with Form
> data being returned from Verisign in later processing.
>

[gfuller]

If you have this problem, check that nslookup for your
domain name actually returns your server's IP address. In
our case, our ISP was not returning the correct IP address
which caused the site domain to mismatch with the IP
causing the 3rd party cookies to alert disallowing session
vars. We called our ISP and they fixed the problem which
was caused by a 'Web forwarding' setting.

Thanks to the Microsoft support lines for solving this one.

>-----Original Message-----
>you may want to use Server.Transfer('page',true) instead

of redirect to

>ensure that the session state is preserved.
>
>"GFuller" <greg.fuller@L-3com.com> wrote in message
>news:018a01c35b74$f19d2ed0$a301280a@phx.gbl...

>> - We have 2 aspx pages in a .NET project. The first

sets

>> a session variable and has a button that when clicked
>> performs a 'redirect' to the second page which then

reads

>> the session variable.
>>
>> Problem: This always works fine on the localserver and
>> through the IDE. But when the application is put onto a
>> www website, the following occurs;
>> - If you browse to the site using the IP address,

session

>> variables work fine
>> - If you browse to the site using the Web Site Domain

Name

>> (ie [url]http://www.tmcontrol.com[/url]) session variables are NOT
>> retrieved properly. Further investigation included
>> outputting the value of Session.SessionID. In the cases
>> where session variables were working (IP browsing) the
>> SessionID matches for both pages. In the case of

failure

>> (name browsing), the SessionIDs are different

indicating a

>> new session.
>>
>> We tried to workaround this issue by setting

SessionState

>> cookieless to "true" in web.config and while this seems

to

>> correct the session problem, it causes problems with

Form

>> data being returned from Verisign in later processing.
>>

>
>
>.
>