| |
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 | |
Share:
| |
"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 | | | |
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
| | | |
"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 | | | |
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
| | | |
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
| | | |
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 | | | |
"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 | | | |
"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. | | | |
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.
| | | |
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.
| | This discussion thread is closed Replies have been disabled for this discussion. Similar topics
7 posts
views
Thread by Eduardo M?ndez |
last post: by
|
1 post
views
Thread by Jon Paugh |
last post: by
|
reply
views
Thread by Fabrício de Novaes Kucinskis |
last post: by
|
2 posts
views
Thread by David Berman |
last post: by
|
reply
views
Thread by Joer996 |
last post: by
|
3 posts
views
Thread by Michael |
last post: by
|
1 post
views
Thread by Mark Baker |
last post: by
|
6 posts
views
Thread by Waldy |
last post: by
|
3 posts
views
Thread by Moe Sisko |
last post: by
| | | | | | | | | | | | | | | | | | | |
