BUG:使用无Cookie会话时,Response.Redirect导致会话过期(.NET 1.1.4322) [英] BUG: Response.Redirect causes premature session expiration when using cookieless sessions (.NET 1.1.4322)

查看:45
本文介绍了BUG:使用无Cookie会话时,Response.Redirect导致会话过期(.NET 1.1.4322)的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

你好帮派,


这个看起来像一个bug:o(


你可能知道也可能不知道,设置会话管理在web.config中使用

cookieless会话导致ASP.NET运行时将会话ID固定为

URL,格式为 http:// yourapplicationpath /(Session.SessionID)/ ...

保存在页面上存储状态时会遇到很多麻烦

请求和会话。


它对我们非常有效 - 我们的网站 www.listersgroup.co.uk 使用

cookieless会话效果良好,其中一个每当我使用Response.Redirect(...)将客户端移动到新页面时,看起来好像是


ASP.NET运行时不是''当无cookie会话被使用时,它可以处理它。


示例:

用您选择的语言创建一个新的Web表单。将web.config文件设置为

使用无cookie会话:


< sessionState mode =" InProc" Cookie的= QUOT;真"超时= QUOT; 30英寸; />


在子程序中的webform中创建条件,通过

页面调用.OnLoad:


if(Request.QueryString(" redirect")=" true"){

Response.Redirect(" thisWebForm.aspx");

} < br $>




如果Request.QueryString(" redirect")=" true"然后

Response.Redirect(" thisWebForm.aspx")

结束如果


观看会话ID,这是进入URL,神奇地忽略了

并且选择了一个新的并重新进入。


这导致了大量的问题,我我正在寻找一个解决方案,无论位置如何,
都能正常工作。如果没有其他人打败我,我会在完成后发布一个

的解决方法!


帮助?


亲切问候,

Anthony

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

推荐答案

" Anthony Williams" <至** @ bigtone.net>在留言中写道

新闻:O6 **************** @ TK2MSFTNGP10.phx.gbl ...
"Anthony Williams" <to**@bigtone.net> wrote in message
news:O6****************@TK2MSFTNGP10.phx.gbl...
嗨帮,

这个看起来像一个bug:o(

你可能知道也可能不知道,将web.config中的会话管理设置为
使用cookieless会话导致ASP.NET运行时将会话ID固定为URL,格式为 http :// yourapplicationpath /(Session.SessionID)/ ...
在页面
请求和会话中存储状态时,可以避免许多麻烦。

它对我们非常有效 - 我们的网站 www.listersgroup.co.uk 使用
无cookie会话效果良好,有一个小缺点。每当我使用Response.Redirect(...)将客户端移动到新页面时,看起来是

ASP.NET运行时并不是为了在无cookie的情况下处理它而构建的正在使用ssions。

示例:
使用您选择的语言创建一个新的Web表单。将web.config文件设置为
使用无cookie会话:

< sessionState mode =" InProc" Cookie的= QUOT;真"超时= QUOT; 30英寸; />

在子程序中的webform中创建一个条件,通过
Page.OnLoad:

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


如果Request.QueryString (redirect)=" true"然后
Response.Redirect(" thisWebForm.aspx")
结束如果

观看会话ID,它被带入URL,神奇地被
忽略选择并重新安装一个新的。

这会导致大量问题,我正在寻找一个解决方案
无论在何处都可以使用。如果没有其他人打败我,我会在完成后立即发布
a解决方法!
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!




您是否尝试包括传递给URL的会话ID

Response.Redirect?

-

John Saunders

johnwsaundersiii at hotmail



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


这可能是个错误,但我不太相信。有几个需要看的东西,以及一些架构决策。


首先,你是否以任何方式进行平衡?如果是这样,你可能会遇到一个问题

,其中包含用于加密ViewState等的密钥。你必须在一个服务器场中手动设置

,即使是一个具有相同状态服务器的服务器。


其次,你是否搞砸了任何状态设置页面,

web.config或machine.config。

第三,事件的泡沫可能会对此产生不利影响。


架构:

ASP.NET中的规范就像ASP一样写,这是一个可怕的趋势,IMO。

这意味着我们写了一个页面中的单个函数,而不是处理页面

就像一个具有多个相关函数的类。要重新构建,你最终可能会使用可用或隐藏的不同面板以及忽略

隐藏输入的路由来结束
,但它会让你解决munge问题cookieless

会话状态。如果您的开发人员没有windows> / b $ b编程的背景知识,那么一些示例应用程序将会降低这一概念。一旦你使用这种方法工作

,你会发现它是合理的,让你远离你所拥有的

问题。你可能在这个周期中来得太晚了。


如果我有机会,我会玩这个,看看我是否能算出来

任何想要帮助你的想法。


-

Gregory A. Beamer

MVP; MCP:+ I,SE,SD,DBA


**************************** ********************

在盒子外面思考!

********* *******************************************

安东尼威廉姆斯" <至** @ bigtone.net>在留言中写道

新闻:O6 **************** @ TK2MSFTNGP10.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.

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...
嗨帮,

这个看起来像一个bug:o(

你可能知道也可能不知道,将web.config中的会话管理设置为
使用cookieless会话导致ASP.NET运行时将会话ID固定为URL,格式为 http :// yourapplicationpath /(Session.SessionID)/ ...
在页面
请求和会话中存储状态时,可以避免许多麻烦。

它对我们非常有效 - 我们的网站 www.listersgroup.co.uk 使用
无cookie会话效果良好,有一个小缺点。每当我使用Response.Redirect(...)将客户端移动到新页面时,看起来是

ASP.NET运行时并不是为了在无cookie的情况下处理它而构建的正在使用ssions。

示例:
使用您选择的语言创建一个新的Web表单。将web.config文件设置为
使用无cookie会话:

< sessionState mode =" InProc" Cookie的= QUOT;真"超时= QUOT; 30英寸; />

在子程序中的webform中创建一个条件,通过
Page.OnLoad:

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


如果Request.QueryString (redirect)=" true"然后
Response.Redirect(" thisWebForm.aspx")
结束如果

观看会话ID,它被带入URL,神奇地被
忽略选择并重新安装一个新的。

这会导致大量问题,我正在寻找一个解决方案
无论在何处都可以使用。如果没有其他人打败我,我会在完成后立即发布
a解决方法!

帮助?

亲切的问候,
Anthony
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]" <否************ @ comcast.netNoSpamM>在消息新闻中写了

:OM ************** @ TK2MSFTNGP09.phx.gbl ...
"Cowboy (Gregory A. Beamer) [MVP]" <No************@comcast.netNoSpamM> wrote
in message news:OM**************@TK2MSFTNGP09.phx.gbl...
这可能是一个错误,但我不太相信。有几个要看的东西,以及一些架构决策。

首先,你是否以任何方式负载均衡?如果是这样,你可能会遇到一个问题
用于加密ViewState等的密钥。您必须在服务器场中手动设置这些,即使是具有相同状态服务器的服务器场。


Nope - 我实际上已禁用ViewState(原本我认为这可能是
实际上是问题的根本原因) - 而我们''我们已经为多台服务器做好了准备 -

machine.config和web.config匹配的所有密钥都没有处于负载均衡状态在每台服务器上。

其次,您是否在页面,
web.config或machine.config中搞乱了任何状态设置。


我所做的唯一改变是将会话超时从20增加到30

分钟:


< sessionState mode =" InProc" Cookie的= QUOT;真"超时= QUOT; 30英寸; />

第三,事件的泡沫可能会对此产生不利影响。


再次,我认为这可能是一个问题,但我们也已经排除了这一点。所有

事件正确触发,冒出正常情况,并且所有内容都应该按原样处理 - 只有在Response.Redirect为
时才会出现问题
用相对URL调用。


此外,似乎 - 当使用调试和监视窗口时 -

Request.Uri.AbsoluteUri .ToString完全忽略了内联munged

SessionID。事实上,Request.Uri的所有方法都忽略了这样一个事实:

在请求的URL中的括号中有一个SessionID。也许这是一个

客户端/服务器通信问题,而不是ASP.NET

运行时本身的问题......我不知道。

架构:
ASP.NET中的规范就像ASP一样编写,这是一个可怕的趋势,IMO。
这意味着我们在页面中编写单个函数,而不是将页面视为具有多个相关功能的类。要重新构建,您可以使用可用或隐藏的不同面板以及忽略隐藏输入的路线结束
,但它会让您解决munge问题。
cookieless
会话状态。如果您的开发人员没有Windows编程的背景知识,那么一些示例应用程序将会降低这一概念。一旦你使用这种方法工作,你会发现它是合理的,让你远离你所遇到的问题。你可能在周期中为时已晚。


我们实际上已经按照与

IBS门户类似的方式设置了我们的项目和课程,其中使用了占位符,用户控件是按照我们正在使用的

数据库/ XML文件中的顺序添加

Placeholder.Controls.Add(LoadControl(" ..."))。

如果我有机会,我会稍微玩一下,看看我是否可以想出任何想法来帮助你。
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.




很酷,虽然有记录,我现在正在使用它作为一种解决方法,并且

似乎工作得很好:


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 S hared 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

感谢您的帮助!如果你确实发现了什么,我会对

看到它非常感兴趣!


问候,

Anthony



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


这篇关于BUG:使用无Cookie会话时,Response.Redirect导致会话过期(.NET 1.1.4322)的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆