【问题标题】:User.Identity.IsAuthenticated False When Debugging in VS2012 Using IISExpress使用 IISExpress 在 VS2012 中调试时 User.Identity.IsAuthenticated False
【发布时间】:2013-11-13 16:13:45
【问题描述】:

我有一个旧的 ASP.NET WebForms 应用程序正在尝试对用户进行身份验证。该应用程序在登台和生产中完美运行。但是,当尝试使用 IISExpress 在本地进行调试时,它不会。

有一个用户控件放置在包含登录服务器控件的母版页中。登录服务器控件有一个自定义模板,并在 OnAuthenticate 事件期间调用 LoginControl_Authenticate。还有一个名为 LoginControl_LoggedIn 的服务器事件在 OnLoggedIn 事件期间被调用。下面是这两种方法的代码:

Private Sub LoginControl_LoggedIn(ByVal sender As Object, ByVal e As System.EventArgs)
    Response.Redirect("~/VerifyAuthentication.aspx", True)
End Sub

Private Sub LoginControl_Authenticate(ByVal sender As Object, ByVal e As AuthenticateEventArgs)
    Dim loginCtrl As Login = CType(LoginContainer.FindControl("LoginControl"), Login)
    Dim username As String = loginCtrl.UserName
    Dim password As String = loginCtrl.Password
    e.Authenticated = Membership.ValidateUser(username, password)
End Sub

VerifyAuthentication.aspx 页面应该随后验证用户并进行一些疯狂的配置文件填充。在 Page_Load 上,第一条语句是检查 User.Identity.IsAuthenticated。同样,在本地,这每次都返回 False。但是,在生产中,它按预期工作。下面是这个方法的一个sn-p:

Private Sub Page_Load(s as Object, e as EventArgs)
    If (User.Identity.IsAuthenticated = False) Then
        ...
    End If
    ...
End Sub

web.config 配置如下:

<system.web>
    <machineKey validationKey="..." decryptionKey="..." validation="SHA1"/>
    <authentication mode="Forms">
        <forms name=".ASPXAUTH" enableCrossAppRedirects="true" timeout="600" defaultUrl="/VerifyAuthentication.aspx" loginUrl="/" protection="All" slidingExpiration="true" domain="localhost" cookieless="UseDeviceProfile" />
    </authentication>
    <membership defaultProvider="DefaultSqlMembershipProvider">
        <providers>
            <clear/>
            <add name="DefaultSqlMembershipProvider" type="System.Web.Security.SqlMembershipProvider" connectionStringName="LocalSqlServer" enablePasswordRetrieval="true" enablePasswordReset="true" requiresQuestionAndAnswer="false" applicationName="/" requiresUniqueEmail="true" passwordFormat="Encrypted" maxInvalidPasswordAttempts="5" minRequiredPasswordLength="7" minRequiredNonalphanumericCharacters="1" passwordAttemptWindow="60" passwordStrengthRegularExpression=""/>
        </providers>
    </membership>
    ...
</system.web>

附带说明一下,IIS Express 以 localhost:1800 的身份运行此应用程序。

编辑(美国东部标准时间 2013 年 14 月 11 日上午 10:00)

应 Scott 的要求,我确实在 Fiddler 中验证了本地版本和生产版本。在这两个版本中,返回的响应都是针对 Set-Cookie。但是,实际上只有生产版本设置了 cookie(这意味着 .ASPXAUTH cookie 出现在公共版本的 cookie 集合中)。

编辑(2013 年 11 月 14 日上午 11:30 EST) 是的。以下是响应和请求标头:

地方发展

从登录:

Response sent 278 bytes of Cookie data:
            Set-Cookie: .ASPXAUTH=AE66DCD41A34991EA27494478D779955ECE7AE3195BC5FE4F19085E9DC3307AF754D540A3B04504DBE65F79F1CFB3FA57780E807D4FA4D8BBD79E09A30BBE40BE4A8D76D26EC3F4FDD335A3667770E3CF7C8D8ACDD3E08B3D5A6B4F076EE5E638B6913DA774A662D300F9E1B554147F9E50D7B65; domain=localhost; path=/; HttpOnly

来自 VerifyAuthentication.aspx

Request sent 42 bytes of Cookie data:

ASP.NET_SessionId=udyfmuy3xg5k3145khptvxer

生产

从登录:

Response sent 291 bytes of Cookie data:
            Set-Cookie: .ASPXAUTH=A34B5A519F2357269239544D4BFAE6DA30C9681F4F2C38D9574F747940C9F27F408AF2BB4A79437DFAB30E18E157D7C7291B1A4BFB98485C93F6427C6851737E8F3C35368A11C053BB5F9E48A0535D5178F10AB9E802C7956C80565F1B2CA042DE51228EF62CAB6B9E3AC748FDA87895B1C3D190; domain=mydomain.com; path=/; HttpOnly

来自 VerifyAuthentication.aspx

Request sent 286 bytes of Cookie data:

ASP.NET_SessionId=ex03esugzcdjuk55tevnfq3o; .ASPXAUTH=A34B5A519F2357269239544D4BFAE6DA30C9681F4F2C38D9574F747940C9F27F408AF2BB4A79437DFAB30E18E157D7C7291B1A4BFB98485C93F6427C6851737E8F3C35368A11C053BB5F9E48A0535D5178F10AB9E802C7956C80565F1B2CA042DE51228EF62CAB6B9E3AC748FDA87895B1C3D190

【问题讨论】:

  • 您是否尝试过使用 Fiddler 检查往返的 HTTP 流量?具体来说,您要检查服务器是否在登录时发回Set-Cookie HTTP 标头,以及在重定向到VerifyAuthentication.aspx 时客户端是否发回Cookie HTTP 标头。
  • 能否将Set-Cookie HTTP 标头的响应以及生产环境和测试环境中请求的 URL 都贴出来?

标签: asp.net visual-studio-2012 asp.net-membership forms-authentication iis-express


【解决方案1】:

我的猜测是它与在 .config 中为 cookie 的域使用“localhost”有关。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2023-03-15
    • 2017-11-07
    • 2017-04-09
    • 2016-10-16
    • 1970-01-01
    • 1970-01-01
    • 2019-06-30
    • 2018-03-14
    相关资源
    最近更新 更多