【问题标题】:Abnormal behaviour of URL Rewrite FilterURL 重写过滤器的异常行为
【发布时间】:2013-02-26 22:14:04
【问题描述】:

我正在使用Tuckey URLRewriteFilter。在我的应用程序中,我有以下页面和按钮:

  1. 页面inside.xhtml在应用程序的上下文中:http://example.com/app/inside.xhtml
  2. 页面outside.xhtml 在应用程序上下文之外:http://example.com/outside.xhtml
  3. 页面login.xhtmlhttp://example.com/app/login.xhtml
  4. login buttonoutside.xhtml 页面上转到login.xhtml 页面。
  5. 页面profile.xhtmlhttp://example.com/app/profile.xhtml
  6. logout buttonprofile.xhtml 页面上转到inside.xhtml 页面。

umlrewrite.xhtml 文件中,我有以下规则从inside.xhtml 重定向到outside.xhtml

<rule>
    <note>
        Requests to /app/inside.xhtml will be redirected to ./../../outside.html
    </note>
    <from>/app/inside.xhtml</from>
    <to type="redirect">./../../outside.html</to>
</rule>

我的逻辑是用户在login.xhtml页面登录后,会被重定向到profile.xhtml页面。我期望发生的是以下流程:

  1. 浏览至outside.xhtml
  2. 点击login button进入login.xhtml并登录。
  3. 登录成功后到达profile.xhtml
  4. 点击logout button转至inside.xhtml
  5. 被重定向到outside.xhtml

然而,实际发生的是:

  1. 浏览至outside.xhtml
  2. 点击login button进入login.xhtml并登录。
  3. 突然被重定向回outside.xhtml
  4. 点击login button转到login.xhtml并再次登录(该应用没有记录我的登录)。
  5. 登录成功后到达profile.xhtml
  6. 点击logout button转至inside.xhtml
  7. 被重定向到outside.xhtml

如果我在步骤7 之后继续执行步骤2,则会重复出现上述情况。

没有&lt;rule&gt;,我总是在成功登录时被重定向到profile.xhtml 页面。

如果您能就这个问题给我一些建议,我将不胜感激。

更新:

在我的应用程序中,为了跟踪 logged in 状态,我有一个 @SessionScoped 托管 bean,其中包含一个记录状态的简单方法:

public void recordUserLoggedIn(HttpServletRequest request) {
    HttpSession clientSession = request.getSession();
    clientSession.setAttribute("isLogin", true);
}

【问题讨论】:

    标签: java jsf-2 url-rewriting tuckey-urlrewrite-filter


    【解决方案1】:

    您没有指定如何跟踪“登录”状态。您是否使用自定义 cookie?依赖应用服务器的内置会话处理(可能也是基于 cookie)?

    问题的最可能原因与您如何跟踪登录状态以及该状态如何在您的各个页面和上下文之间传递有关。 (尤其是从登录状态转换到 profile.xhtml 时。)请记住,cookie 可以是基于路径的。

    调试你的问题:

    • 如果您使用浏览器,请使用firebug/developer-tools 并查看网络选项卡。尤其要查看在流程的每个步骤中设置的各种标题。

    • 如果不使用浏览器,请尝试使用代理,例如 CharlesFiddler

    我认为通过在您的流程中观察 HTTP 标头,潜在的问题会变得很明显。

    【讨论】:

    • 我已经更新了我的答案。那是你需要的吗?需要注意的一件事是,如果没有 rule,一切正常。我想我应该正确记录了logged in 状态。
    • 您的更新表明您依赖于容器的会话处理。我最好的猜测是您的容器将会话 cookie 设置为当前路径(“/app”)。然后,当您重定向到父级时,会话将丢失,直到您再次登录。这只是一个猜测。根据我的回答,您确实需要查看 HTTP 请求中的 cookie 标头。如果更容易,您还可以尝试在流程的各个阶段记录会话 ID。我的猜测是,即使您不希望它发生变化,它也会发生变化。
    猜你喜欢
    • 2013-03-16
    • 2011-07-25
    • 1970-01-01
    • 2016-02-28
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多