Response.Redirect失败，但随后在刷新IIS VS2013上工作

Question

我在Visual 2013中有一个ASP.NET项目，在IIExpress (版本8.08418.0)中本地运行以进行测试。

主页( adminDefault.aspx )将用户重定向到Login.aspx以进行身份验证(这是基于作为url变量传递给adminDefault.aspx的userID进行的)。成功的身份验证后，登录页面将其发送回adminDefault.aspx。默认情况下，然后将数据加载到Gridview中。

整个过程大约需要15秒。

当我从Visual 2013运行这个程序时，我会在大约4秒内得到一个错误“此页面无法显示”。但是如果我手动点击刷新，在工作一段时间后，一切都会好起来。

​

​

在我的代码中，由于怀疑超时，我隐式地设置了足够长的时间来运行所有内容：

 if (!this.IsPostBack)
            {

                Session.Timeout = 120;  // seconds before timeout
                try
                {
                    // OnUser should have been set from Login.asp. If it is null, send to Login
                    MembershipUser onUser = Membership.GetUser();
                    if (onUser == null)
                    {
                        Response.Redirect("/login.aspx", true);
                    }
                    else
                    {
                        String currentUserName = Membership.GetUser().UserName;
                        userRoles = Roles.GetRolesForUser(Membership.GetUser().UserName);
                    }
                }

即使Session.Timeout被忽略了，缺省值也是20秒，所以我希望它无论如何都能工作。

所以：( 1)为什么第一次失败？( 2)我有办法阻止它吗？如果没有，我可以捕获未找到的页面，并自动刷新吗？

编辑:这与去Login.aspx和回来的旅行有关。如果我删除了Response.Redirect("/login.aspx", true);，那么它就会像预期的那样工作。问题是，我需要Login.aspx进行验证。有谁想过为什么去登录和回来的旅行不管用.然后在刷新的时候做呢？

当我尝试在Chrome上运行这个程序时，我没有达到这个目的。Chrome给我看了这个：

​

​

点击这里的，就会循环一会儿，然后回到屏幕上。

在这种情况下，IE上的开发工具是没有帮助的(至少我可以看到)。当我在调试器中运行我的项目时，它会启动一个新的IE会话。在我打开开发人员工具并按"Play“来记录事件之前，会话给了我”无法显示页面“错误。当然，我可以在工具中点击"play“，然后刷新，但是当然，所有的操作都没有出错。刷新使一切正常运行。我需要在那之前找出失败的原因。

编辑:这是Login.aspx和Web.Security代码。我没有写，但它看起来像样板：

  protected void Page_Load(object sender, EventArgs e)
    {
            string userName = "";
            bool authenticated = FormsAuthentication.Authenticate(ref userName);
            if (authenticated)
                {
                    FormsAuthentication.RedirectFromLoginPage(userName, false);
                }
     }

和身份验证代码如下所示：

        /// <summary>
    /// Validates a user based on the  session id found in the ReturnURL against credentials stored in the ASP.NET membership.
    /// </summary>
    /// <param name="userName">The user name.</param>
    /// <returns>true if the user name and password are valid; otherwise, false.</returns>
    public static bool Authenticate(ref string userName)
    {
        bool Authenticated = Authenticate(ref userName, GetSessionId());
        return Authenticated;
    }

    /// <summary>
    /// Redirects an authenticated user back to the originally requested URL or the default URL using the specified cookie path for the forms-authentication cookie.
    /// </summary>
    /// <param name="userName">The authenticated user name. </param>
    /// <param name="createPersistentCookie">true to create a durable cookie (one that is saved across browser sessions); otherwise, false. </param>
    /// <param name="strCookiePath">The cookie path for the forms-authentication ticket. </param>
    public static void RedirectFromLoginPage(string userName, bool createPersistentCookie, string strCookiePath)
    {
        System.Web.Security.FormsAuthentication.SetAuthCookie(userName, false, strCookiePath);

        // Redirect back to request page.
        HttpContext.Current.Response.Redirect(GetRedirectUrl());
    }

Answer 1

我认为，在初始的if状态中，假设每个人都已登录或未登录in.But用户，访问的用户也可以是匿名的(?)。您要做的是保护此admin.Default页面的安全，并且只允许授权用户。目前，如果用户= null或获得一个角色，那么您的2个条件将返回用户到login.aspx页面(它们当前在该页面上)。身份验证是知道用户是谁，而授权则是访问资源，.You只希望授权用户访问该资源。

我会将admin.Default.aspx、admin.Default.cs和admin.Default.designer.cs放在他们自己的文件夹AdminSecure中。然后在该文件夹中添加它们之后，右键单击并添加一个Web.config文件。在这个Web.config中，您需要做的是拒绝匿名用户。因此，当他们尝试访问AdminDefault页面时，会自动被重定向。

//拒绝非登录用户？==匿名

<xml version="1.0"?>
<configuration>
    <system.web>
<authorization>
  <deny users="?"/>
</authorization>
    </system.web>
</configuration>


//this can allow particular users
<allow users="User1@mail.com"/>

//deny everyone but one user:
<allow users="User1@mail.com"/>
<deny users="*"/>

注释掉您当前的代码，希望这有帮助。

Answer 2

如果Login.aspx在将会话持久化到浏览器之前重定向到adminDefault.aspx，则会发生无限重定向循环。

我的线索：

1)由于您已经有了一个重定向循环--尽管不是有意无限的--在未处理的情况下就有无限的风险。

2)您说可能发生超时，但是忽略了服务器端超时:这使我认为这种超时发生在客户端，实际上可能是浏览器破坏重定向循环作为安全措施。

3)刷新帮助:在会话被持久化客户端之后，这会中断重定向循环。

4)删除对adminDefault.aspx的重定向很有帮助:这不仅破坏了无限循环，而且消除了重定向循环的概念

您可以做几件事来测试重定向循环理论：

1)在Session.Timeout = 120;上设置一个断点，看看事情从那里走向何方。您希望只访问Response.Redirect("/login.aspx", true);一次，但很可能会看到这一行被连续击中(每次重定向一次)。

或

2)安装费德勒并监控您的重定向。

如果上述理论是正确的，则必须确保Login.aspx在重定向到adminDefault.aspx之前将会话持久化到浏览器。也就是说，尝试移除重定向到adminDefault.aspx，看看在重定向到Login.aspx之后是否得到了会话cookie --如果没有，您就有了嫌疑人。简而言之，Login.aspx在您重定向回adminDefault.aspx之前还没有完成它的工作，所以您必须让它完成。没有Login.aspx代码，我再详细不过了。

Answer 3

根据注释中的应用程序环境，您无法通过web.config管理身份验证/授权。而且，如果您有自定义提供程序，通常会访问Membership类，这不是访问登录用户的默认方式。这两种方法都是这样的：

1. 以下列方式检查if语句中的登录用户： 如果(User.Identity.IsAuthenticated) { Response.Redirect("/login.aspx"，true)；} roles { String currentUserName = Use User.Identity.Name；//访问登录的uer userRoles = Roles.GetRolesForUser(currentUserName)；//不确定此步骤，您是否将角色添加到web.Config？或者你从哪里得到它们}
2. 取决于您的ERP如何与您的应用程序集成(您应该使用自定义提供程序)，检查用户在哪里获得身份验证。(例如他正在给Membership.ValidateUser(strUsername,strPassword)打电话。并确保您的login.aspx页面正在更新会话状态。

有关实现自定义提供程序的更多信息，请查看此页。