302登录重定向后IE删除的URL片段 [英] URL fragment removed by IE after 302 login redirect

问题描述

我们在应用程序中使用 SiteMinder 身份验证.

We use SiteMinder authentication in our application.

如果应用程序用户尝试通过直接URL或通过加书签的URL导航到我们应用程序中的特定页面https://ourapp.com/myapp/#/pending/requests，则SiteMinder将通过302重定向重定向到login page，类似于http://ourapp.com/login?redirect=https%3A%2F%2Fourapp.com%2Fmyapp%2F#/pending/requests，要求用户输入登录形式的凭据.成功通过身份验证后，应将用户重定向到我们的应用并登陆到请求的页面(/pending/requests).

If app user tries to navigate to a particular page https://ourapp.com/myapp/#/pending/requests in our app via direct URL or via bookmarked URL, SiteMinder will redirect to a login page via 302 redirect similar to http://ourapp.com/login?redirect=https%3A%2F%2Fourapp.com%2Fmyapp%2F#/pending/requests asking for user to enter credential in a login form. After successful authentication, user should be redirected to our app and land on the requested page(/pending/requests).

在Chrome和Firefox中，它绝对可以正常工作.谈到IE，它是在https://ourapp.com/myapp/#/home(默认目标网页)而不是https://ourapp.com/myapp/#/pending/requests上登陆.

It's working absolutely fine in Chrome and Firefox. When it comes to IE it's landing on https://ourapp.com/myapp/#/home (default landing page) instead of https://ourapp.com/myapp/#/pending/requests.

我已经尝试了google search results中我们的应用程序代码中提供的各种解决方案，例如

I have tried various solutions provided in google search results in our app code like,

• 在index.html
中删除<base>标签
• 在页面顶部添加以下代码行

// setting location back
window.location = window.location;

// setting location hash back
window.location.hash = window.location.hash;

• 几乎没有其他与上述类似的解决方案

尽管此问题与解答； A 完全有道理，

我仍然想按preserve the URL hash fragment in IE even it's 3xx redirect的要求...！?

I still want to preserve the URL hash fragment in IE even it's 3xx redirect for my requirement...!?

推荐答案

回答我自己的问题

我发现，成功认证后，SiteMinder通过使用登录表单隐藏变量value (在其中存储用户请求的URL /myapp/)对用户请求的应用程序页面执行302 redirection. -without hash fragment，因为它不会被发送到服务器)，其名称类似于redirect.下面的示例表格

Answering my own Question

I figured out that after successful authentication, SiteMinder is doing 302 redirection to user requested application page by using login form hidden variable value (where it stores user requested URL /myapp/ - without hash fragment since it won't be sent to the server) with name similar to redirect. Sample form below

由于redirect隐藏变量 value 仅包含/myapp/，没有散列片段，并且是302重定向，因此即使在进入我们的应用程序之前，IE也会自动删除该散列片段，无论我们使用什么解决方案尝试我们的应用程序代码无法解决问题.

Since redirect hidden variable value contains only /myapp/ without hash fragment and it's a 302 redirect, the hash fragment is automatically removed by IE even before coming to our application and whatever the solutions we are trying in our application code are not working out.

IE仅重定向到/myapp/，并且它已登陆我们应用程序https://ourapp.com/myapp/#/home的默认主页.

IE is redirecting to /myapp/ only and it is landing on default home page of our app https://ourapp.com/myapp/#/home.

浪费了几乎一天的时间来弄清这种行为.

Have wasted almost a day to figure out this behavior.

已更改登录表单隐藏变量(redirect)值，以保留哈希片段 将window.location.hash与现有值一起附加.类似于下面的代码

Have changed the login form hidden variable (redirect) value to hold the hash fragment by appending window.location.hash along with existing value. Similar to below code

$(function () {
  var $redirect = $('input[name="redirect"]');
  $redirect.val($redirect.val() + window.location.hash);
});

此更改之后，redirect隐藏变量将用户请求的URL值存储为/myapp/#/pending/requests，而SiteMinder会将其重定向到IE中的/myapp/#/pending/requests.

After this change, the redirect hidden variable is storing user requested URL value as /myapp/#/pending/requests and SiteMinder is redirecting it to /myapp/#/pending/requests in IE.

上述解决方案在所有三个浏览器Chrome, Firefox and IE中均能正常工作.

The above solution is working fine in all the three browsers Chrome, Firefox and IE.

感谢@AlexFord提供的详细信息解释并提供解决方案.

Thanks to @AlexFord for the detailed explanation and providing solution to this issue.

这篇关于302登录重定向后IE删除的URL片段的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！