Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > BUG: Response.Redirect causes premature session expiration when using cookieless sessions (.NET 1.1.4322)

Reply
Thread Tools

BUG: Response.Redirect causes premature session expiration when using cookieless sessions (.NET 1.1.4322)

 
 
Anthony Williams
Guest
Posts: n/a
 
      06-08-2004
Hi gang,

This one looks like a bug (

As you may or may not know, setting session management in web.config to use
cookieless sessions causes the ASP.NET runtime to munge a session ID into
the URL, in the format http://yourapplicationpath/(Session.SessionID)/...
which saves numerous headaches when it comes to storing state across page
requests and sessions.

It works very well for us - our website at www.listersgroup.co.uk uses
cookieless sessions to good effect, with one minor drawback. It appears that
whenever I use Response.Redirect(...) to move the client to a new page, the
ASP.NET runtime wasn't built to handle it when cookieless sessions were
being used.

Example:
Create a new Web Form in your chosen language. Set the web.config file to
use cookieless sessions:

<sessionState mode="InProc" cookieless="true" timeout="30" />

Make a condition in your webform in the Subroutine which is called via
Page.OnLoad:

if (Request.QueryString("redirect") = "true") {
Response.Redirect("thisWebForm.aspx");
}

or

If Request.QueryString("redirect") = "true" Then
Response.Redirect("thisWebForm.aspx")
End If

Watch as the session ID, which is munged into the URL, is magically ignored
and a new one is chosen and re-munged in.

This is causing loads of problems, and I'm looking to find a solution which
will work regardless of location. If no-one else beats me to it, I'll post a
workaround as soon as I'm done!

Help?

Kind regards,
Anthony


 
Reply With Quote
 
 
 
 
John Saunders
Guest
Posts: n/a
 
      06-08-2004
"Anthony Williams" <(E-Mail Removed)> wrote in message
news:O6zcd%(E-Mail Removed)...
> Hi gang,
>
> This one looks like a bug (
>
> As you may or may not know, setting session management in web.config to

use
> cookieless sessions causes the ASP.NET runtime to munge a session ID into
> the URL, in the format http://yourapplicationpath/(Session.SessionID)/...
> which saves numerous headaches when it comes to storing state across page
> requests and sessions.
>
> It works very well for us - our website at www.listersgroup.co.uk uses
> cookieless sessions to good effect, with one minor drawback. It appears

that
> whenever I use Response.Redirect(...) to move the client to a new page,

the
> ASP.NET runtime wasn't built to handle it when cookieless sessions were
> being used.
>
> Example:
> Create a new Web Form in your chosen language. Set the web.config file to
> use cookieless sessions:
>
> <sessionState mode="InProc" cookieless="true" timeout="30" />
>
> Make a condition in your webform in the Subroutine which is called via
> Page.OnLoad:
>
> if (Request.QueryString("redirect") = "true") {
> Response.Redirect("thisWebForm.aspx");
> }
>
> or
>
> If Request.QueryString("redirect") = "true" Then
> Response.Redirect("thisWebForm.aspx")
> End If
>
> Watch as the session ID, which is munged into the URL, is magically

ignored
> and a new one is chosen and re-munged in.
>
> This is causing loads of problems, and I'm looking to find a solution

which
> will work regardless of location. If no-one else beats me to it, I'll post

a
> workaround as soon as I'm done!


Did you try to include the session id in the URL passed to
Response.Redirect?
--
John Saunders
johnwsaundersiii at hotmail


 
Reply With Quote
 
 
 
 
Cowboy \(Gregory A. Beamer\) [MVP]
Guest
Posts: n/a
 
      06-08-2004
This might well be a bug, but I am not quite convinced. There are a couple
of things to look at, as well as some architectural decisions.

First, are you load balanced in any way? If so, you may have an issue here
with the keys used to encrypt ViewState, et al. You have to manually set
these in a farm, even one with the same state server.

Second, have you messed with any state settings in either the page, the
web.config or machine.config.

Third, it is possible that bubble up of events affects this adversely.

Architectural:
The norm in ASP.NET is writing it like ASP, which is a horrible trend, IMO.
This means we write a single function in a page, rather than treat a page
like a class with multiple related functions. To rearchitect, you may end up
with different panels that are available or hidden, and routes that ignore
the hidden input, but it will get you around the munge issue with cookieless
session state. If your developers do not have a background in windows
programming, a few sample apps will get this concept down. Once you work
with the methodology, you will find it is sound and gets you away from the
issue you are having. You may be too late in the cycle to do this.

If I get the chance, I will play with this a bit and see if I can figure out
any ideas to aid you.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

************************************************
Think Outside the Box!
************************************************
"Anthony Williams" <(E-Mail Removed)> wrote in message
news:O6zcd%(E-Mail Removed)...
> Hi gang,
>
> This one looks like a bug (
>
> As you may or may not know, setting session management in web.config to

use
> cookieless sessions causes the ASP.NET runtime to munge a session ID into
> the URL, in the format http://yourapplicationpath/(Session.SessionID)/...
> which saves numerous headaches when it comes to storing state across page
> requests and sessions.
>
> It works very well for us - our website at www.listersgroup.co.uk uses
> cookieless sessions to good effect, with one minor drawback. It appears

that
> whenever I use Response.Redirect(...) to move the client to a new page,

the
> ASP.NET runtime wasn't built to handle it when cookieless sessions were
> being used.
>
> Example:
> Create a new Web Form in your chosen language. Set the web.config file to
> use cookieless sessions:
>
> <sessionState mode="InProc" cookieless="true" timeout="30" />
>
> Make a condition in your webform in the Subroutine which is called via
> Page.OnLoad:
>
> if (Request.QueryString("redirect") = "true") {
> Response.Redirect("thisWebForm.aspx");
> }
>
> or
>
> If Request.QueryString("redirect") = "true" Then
> Response.Redirect("thisWebForm.aspx")
> End If
>
> Watch as the session ID, which is munged into the URL, is magically

ignored
> and a new one is chosen and re-munged in.
>
> This is causing loads of problems, and I'm looking to find a solution

which
> will work regardless of location. If no-one else beats me to it, I'll post

a
> workaround as soon as I'm done!
>
> Help?
>
> Kind regards,
> Anthony
>
>



 
Reply With Quote
 
Anthony Williams
Guest
Posts: n/a
 
      06-08-2004
"Cowboy (Gregory A. Beamer) [MVP]" <(E-Mail Removed)> wrote
in message news:(E-Mail Removed)...
> This might well be a bug, but I am not quite convinced. There are a couple
> of things to look at, as well as some architectural decisions.
>
> First, are you load balanced in any way? If so, you may have an issue here
> with the keys used to encrypt ViewState, et al. You have to manually set
> these in a farm, even one with the same state server.


Nope - I've actually disabled ViewState (originally I thought this may
actually be the root cause of the problem) - and whilst we're not in a
load-balanced situation (yet) we're already prepared for multiple servers -
all of the keys in machine.config and web.config match on each server.

> Second, have you messed with any state settings in either the page, the
> web.config or machine.config.


The only change I've made is to increase the session timeout from 20 to 30
minutes:

<sessionState mode="InProc" cookieless="true" timeout="30" />

> Third, it is possible that bubble up of events affects this adversely.


Again, I thought this might be a problem, but we've ruled this out too. All
the events fire correctly, bubbling up as they should, and everything is
handled as it should be - the problem occurs only when Response.Redirect is
called with a relative URL.

Also, it appears that - when using debug and the watch windows - that
Request.Uri.AbsoluteUri.ToString completely ignores the inline munged
SessionID. In fact, all the methods of Request.Uri ignore the fact that
there is a SessionID in parenthesis in the requested URL. Perhaps this is a
client/server communication problem, and not a problem in the ASP.NET
runtime itself... I don't know.

> Architectural:
> The norm in ASP.NET is writing it like ASP, which is a horrible trend,
> IMO.
> This means we write a single function in a page, rather than treat a page
> like a class with multiple related functions. To rearchitect, you may end
> up
> with different panels that are available or hidden, and routes that ignore
> the hidden input, but it will get you around the munge issue with
> cookieless
> session state. If your developers do not have a background in windows
> programming, a few sample apps will get this concept down. Once you work
> with the methodology, you will find it is sound and gets you away from the
> issue you are having. You may be too late in the cycle to do this.


We've actually got our project and classes set up in a similar way to the
IBS portal, whereby placeholders are used, and User Controls are added using
Placeholder.Controls.Add(LoadControl("...")) in the order in the
database/XML file we're using.

> If I get the chance, I will play with this a bit and see if I can figure
> out
> any ideas to aid you.


Cool, though for the record, I'm currently using this as a workaround, and
it seems to work just fine:

Public Shared Sub ResponseRedirect()
HttpContext.Current.Response.Redirect(HttpContext. Current.Request.Url.AbsoluteUri.ToLower.Replace(Ht tpContext.Current.Request.ApplicationPath.ToLower,
HttpContext.Current.Request.ApplicationPath.ToLowe r + "/(" +
HttpContext.Current.Session.SessionID + ")"))
End Sub
Public Shared Sub ResponseRedirect(ByVal PathAndQuery As String)
HttpContext.Current.Response.Redirect(HttpContext. Current.Request.Url.Scheme
+ HttpContext.Current.Request.Url.SchemeDelimiter +
HttpContext.Current.Request.Url.Host +
HttpContext.Current.Request.ApplicationPath + "/(" +
HttpContext.Current.Session.SessionID + ")/" + PathAndQuery)
End Sub


Thanks for the help! If you do find anything out, I'd be very interested in
seeing it!

Regards,
Anthony


 
Reply With Quote
 
Anthony Williams
Guest
Posts: n/a
 
      06-08-2004
John,

When using relative URL fragments, it's not that easy to simply include the
munged sessionID - I've posted a workaround, as a reply to Gregory's
response, which shows how I'm getting around the problem, by using an
absolute URL which is pieced together using various
HttpContext.Current.Request objects and putting the SessionID in manually.

Regards,
Anthony

"John Saunders" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "Anthony Williams" <(E-Mail Removed)> wrote in message
> news:O6zcd%(E-Mail Removed)...
>> Hi gang,
>>
>> This one looks like a bug (
>>
>> As you may or may not know, setting session management in web.config to

> use
>> cookieless sessions causes the ASP.NET runtime to munge a session ID into
>> the URL, in the format http://yourapplicationpath/(Session.SessionID)/...
>> which saves numerous headaches when it comes to storing state across page
>> requests and sessions.
>>
>> It works very well for us - our website at www.listersgroup.co.uk uses
>> cookieless sessions to good effect, with one minor drawback. It appears

> that
>> whenever I use Response.Redirect(...) to move the client to a new page,

> the
>> ASP.NET runtime wasn't built to handle it when cookieless sessions were
>> being used.
>>
>> Example:
>> Create a new Web Form in your chosen language. Set the web.config file to
>> use cookieless sessions:
>>
>> <sessionState mode="InProc" cookieless="true" timeout="30" />
>>
>> Make a condition in your webform in the Subroutine which is called via
>> Page.OnLoad:
>>
>> if (Request.QueryString("redirect") = "true") {
>> Response.Redirect("thisWebForm.aspx");
>> }
>>
>> or
>>
>> If Request.QueryString("redirect") = "true" Then
>> Response.Redirect("thisWebForm.aspx")
>> End If
>>
>> Watch as the session ID, which is munged into the URL, is magically

> ignored
>> and a new one is chosen and re-munged in.
>>
>> This is causing loads of problems, and I'm looking to find a solution

> which
>> will work regardless of location. If no-one else beats me to it, I'll
>> post

> a
>> workaround as soon as I'm done!

>
> Did you try to include the session id in the URL passed to
> Response.Redirect?
> --
> John Saunders
> johnwsaundersiii at hotmail
>
>



 
Reply With Quote
 
Brad
Guest
Posts: n/a
 
      06-09-2004
Anthony - Here's a stupid question. Does your app write anything to
session? I don't know about cookiesless but my understanding of inproc
session is that sessionid is not persisted until something adds to session
i.e. a simple session.Add("myVar","Hello World") will cause sessionid to be
persisted.

Brad



"Anthony Williams" <(E-Mail Removed)> wrote in message
news:O6zcd%(E-Mail Removed)...
> Hi gang,
>
> This one looks like a bug (
>
> As you may or may not know, setting session management in web.config to

use
> cookieless sessions causes the ASP.NET runtime to munge a session ID into
> the URL, in the format http://yourapplicationpath/(Session.SessionID)/...
> which saves numerous headaches when it comes to storing state across page
> requests and sessions.
>
> It works very well for us - our website at www.listersgroup.co.uk uses
> cookieless sessions to good effect, with one minor drawback. It appears

that
> whenever I use Response.Redirect(...) to move the client to a new page,

the
> ASP.NET runtime wasn't built to handle it when cookieless sessions were
> being used.
>
> Example:
> Create a new Web Form in your chosen language. Set the web.config file to
> use cookieless sessions:
>
> <sessionState mode="InProc" cookieless="true" timeout="30" />
>
> Make a condition in your webform in the Subroutine which is called via
> Page.OnLoad:
>
> if (Request.QueryString("redirect") = "true") {
> Response.Redirect("thisWebForm.aspx");
> }
>
> or
>
> If Request.QueryString("redirect") = "true" Then
> Response.Redirect("thisWebForm.aspx")
> End If
>
> Watch as the session ID, which is munged into the URL, is magically

ignored
> and a new one is chosen and re-munged in.
>
> This is causing loads of problems, and I'm looking to find a solution

which
> will work regardless of location. If no-one else beats me to it, I'll post

a
> workaround as soon as I'm done!
>
> Help?
>
> Kind regards,
> Anthony
>
>



 
Reply With Quote
 
Steven Cheng[MSFT]
Guest
Posts: n/a
 
      06-09-2004
Hi Anthony,

Based on my test, I just create a two simple pages in my web project ,
page1.aspx and page2.aspx. I set the session as inprocess and cookieless.
And in page1.aspx, I use the following code in a button's click eventhandler

Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Response.Redirect("page2.aspx")

End Sub

and I've also tried Server.Transfer("page2.aspx"), they all works well
without starting a new sessionid in url. But I did meet problems when
change the url path as root based url such as

Response.Redirect("/approot/page2.aspx") and also found the following
article which also mentioned this behavior
http://www.eggheadcafe.com/PrintSear...asp?LINKID=401

Hope helps.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

Get Preview at ASP.NET whidbey
http://msdn.microsoft.com/asp.net/whidbey/default.aspx





 
Reply With Quote
 
Anthony Williams
Guest
Posts: n/a
 
      06-09-2004
"Anthony Williams" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...

> I'm currently using this as a workaround, and it seems to work just fine:
>
> Public Shared Sub ResponseRedirect()
>
> HttpContext.Current.Response.Redirect(HttpContext. Current.Request.Url.AbsoluteUri.ToLower.Replace(Ht tpContext.Current.Request.ApplicationPath.ToLower,
> HttpContext.Current.Request.ApplicationPath.ToLowe r + "/(" +
> HttpContext.Current.Session.SessionID + ")"))
> End Sub
> Public Shared Sub ResponseRedirect(ByVal PathAndQuery As String)
>
> HttpContext.Current.Response.Redirect(HttpContext. Current.Request.Url.Scheme
> + HttpContext.Current.Request.Url.SchemeDelimiter +
> HttpContext.Current.Request.Url.Host +
> HttpContext.Current.Request.ApplicationPath + "/(" +
> HttpContext.Current.Session.SessionID + ")/" + PathAndQuery)
> End Sub
>


Anyone using the above may wish to try this newer, more reliable version
out:

Public Shared Sub Redirect()
HttpContext.Current.Response.Redirect( _
HttpContext.Current.Request.Url.AbsoluteUri.ToLowe r.Replace( _
HttpContext.Current.Request.ApplicationPath.ToLowe r, _
HttpContext.Current.Request.ApplicationPath.ToLowe r & _
"/(" & HttpContext.Current.Session.SessionID & ")"))
End Sub

Public Shared Sub Redirect(ByVal PathAndQuery As String)
Dim RedirectUrl As String
If HttpContext.Current.Request.ApplicationPath = "/" Then
RedirectUrl = HttpContext.Current.Request.Url.Scheme &
HttpContext.Current.Request.Url.SchemeDelimiter &
HttpContext.Current.Request.Url.Host & "/(" &
HttpContext.Current.Session.SessionID & ")"
Else
RedirectUrl = HttpContext.Current.Request.Url.Scheme &
HttpContext.Current.Request.Url.SchemeDelimiter &
HttpContext.Current.Request.Url.Host &
HttpContext.Current.Request.ApplicationPath & "/(" &
HttpContext.Current.Session.SessionID & ")"
End If

RedirectUrl &= IIf(PathAndQuery.StartsWith("/"), "", "/") &
PathAndQuery

HttpContext.Current.Response.Redirect(RedirectUrl)
End Sub


 
Reply With Quote
 
Anthony Williams
Guest
Posts: n/a
 
      06-09-2004
"Brad" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Anthony - Here's a stupid question. Does your app write anything to
> session? I don't know about cookiesless but my understanding of inproc
> session is that sessionid is not persisted until something adds to session
> i.e. a simple session.Add("myVar","Hello World") will cause sessionid to
> be
> persisted.


AFAIK, Session.SessionID is persisted from the first request, though my
Global class sets quite a few things on Session_Start.


 
Reply With Quote
 
Brad
Guest
Posts: n/a
 
      06-09-2004
Hmmm. I tried your example and the cooklies id is remaining constant for
me. Did a response redirect based on querystring param and response
redirect based on postback of a link button and in both instances the munged
id in the url remained constant. This was tested using framework 1.1
(vs2003) on win2003 server.

Brad

"Anthony Williams" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "Brad" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > Anthony - Here's a stupid question. Does your app write anything to
> > session? I don't know about cookiesless but my understanding of inproc
> > session is that sessionid is not persisted until something adds to

session
> > i.e. a simple session.Add("myVar","Hello World") will cause sessionid

to
> > be
> > persisted.

>
> AFAIK, Session.SessionID is persisted from the first request, though my
> Global class sets quite a few things on Session_Start.
>
>



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Cookieless Sessions (Sessions Without Cookies) and Security scottymo ASP .Net Security 3 09-29-2006 11:00 PM
sessionState cookieless and forms cookieless ravisingh11@gmail.com ASP .Net 2 05-09-2006 11:26 PM
Premature WinXP x64 trial expiration =?Utf-8?B?QU1ENG1lMg==?= Windows 64bit 4 06-08-2005 02:57 PM
Cookieless session, but session ID as a query string Hope Paka ASP .Net 0 06-07-2005 06:25 PM
Session contents lost despite Session.Timeout = 3000; and <sessionState mode="InProc" cookieless="false" timeout="300"> Carpe Diem ASP .Net 3 02-23-2004 07:10 PM



Advertisments