473,287 Members | 1,800 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,287 software developers and data experts.

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

Hi gang,

This one looks like a bug :o(

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
Nov 18 '05 #1
10 7825
"Anthony Williams" <to**@bigtone.net> wrote in message
news:O6****************@TK2MSFTNGP10.phx.gbl...
Hi gang,

This one looks like a bug :o(

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
Nov 18 '05 #2
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" <to**@bigtone.net> wrote in message
news:O6****************@TK2MSFTNGP10.phx.gbl...
Hi gang,

This one looks like a bug :o(

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

Nov 18 '05 #3
"Cowboy (Gregory A. Beamer) [MVP]" <No************@comcast.netNoSpamM> wrote
in message news:OM**************@TK2MSFTNGP09.phx.gbl...
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
Nov 18 '05 #4
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" <jo**************@notcoldmail.com> wrote in message
news:eg**************@tk2msftngp13.phx.gbl...
"Anthony Williams" <to**@bigtone.net> wrote in message
news:O6****************@TK2MSFTNGP10.phx.gbl...
Hi gang,

This one looks like a bug :o(

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

Nov 18 '05 #5
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" <to**@bigtone.net> wrote in message
news:O6****************@TK2MSFTNGP10.phx.gbl...
Hi gang,

This one looks like a bug :o(

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

Nov 18 '05 #6
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

Nov 18 '05 #7
"Anthony Williams" <to**@bigtone.net> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
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
Nov 18 '05 #8
"Brad" <no****@co.lane.or.us> wrote in message
news:u8**************@TK2MSFTNGP12.phx.gbl...
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.
Nov 18 '05 #9
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" <to**@bigtone.net> wrote in message
news:eT*************@TK2MSFTNGP12.phx.gbl...
"Brad" <no****@co.lane.or.us> wrote in message
news:u8**************@TK2MSFTNGP12.phx.gbl...
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.

Nov 18 '05 #10
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" <to**@bigtone.net> wrote in message
news:eT*************@TK2MSFTNGP12.phx.gbl...
"Brad" <no****@co.lane.or.us> wrote in message
news:u8**************@TK2MSFTNGP12.phx.gbl...
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.

Nov 18 '05 #11

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

7
by: Eduardo M?ndez | last post by:
Hello: I have an aspx page with a TextBox and a DropDownListBox both have Autopostback property set to true and some code in the TextChanged and SelectedIndexChanged events. When text in...
1
by: Jon Paugh | last post by:
Hi, So in Application_Error method in Global class of my ASP.NET web project, I add: HttpContext.Current.Session = "SomeSessionThing"; Then, in Application_Error method I...
0
by: Fabrício de Novaes Kucinskis | last post by:
Hi all, My ASP.net application uses Windows Authentication. When using Forms Authentication, if the session expires, the common thing to do is to redirect the user to the login page again. ...
2
by: David Berman | last post by:
It seems that my site is losing session information when using Server.Transfer. I have a page called PictureGallery.aspx. It takes an argument which is an index id, so it would look like...
0
by: Joer996 | last post by:
I am using StateServer and URIs to manage state. Here is my web.config line <sessionState mode="StateServer" stateConnectionString="tcpip=localhost:42424" cookieless="UseUri" timeout="500"/> ...
3
by: Michael | last post by:
Hi, If I use SQL Server to store session state, whenever I call Session is there a call to SQL Server? Even if I call Session a few times in the same Web page, or even the same code block? ...
1
by: Mark Baker | last post by:
Hi, I am using Cookieless Forms Authentication. Due to this I get the session ID in the URL as follows: http://localhost/testcookie/(S(112ny2vvuypkkg55pzcyk4qd))/default.aspx How can I hide...
6
by: Waldy | last post by:
Hi there, I have a very simple three page web application that I am having trouble with. If there are any problems with any of the parameters that are passed to the first page, I want to redirect...
3
by: Moe Sisko | last post by:
Using dotnet 2.0 sp1, I've got ASP.NET session state working ok in SQLServer mode, but the sessions never seem to expire. e.g if I add a timeout attribute like so : <sessionState...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM). In this month's session, the creator of the excellent VBE...
0
by: MeoLessi9 | last post by:
I have VirtualBox installed on Windows 11 and now I would like to install Kali on a virtual machine. However, on the official website, I see two options: "Installer images" and "Virtual machines"....
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: Aftab Ahmad | last post by:
So, I have written a code for a cmd called "Send WhatsApp Message" to open and send WhatsApp messaage. The code is given below. Dim IE As Object Set IE =...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: marcoviolo | last post by:
Dear all, I would like to implement on my worksheet an vlookup dynamic , that consider a change of pivot excel via win32com, from an external excel (without open it) and save the new file into a...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.