如何处理路由中的额外哈希？ （AngularJS 1.5 + new/component 路由器）
How to deal with extra hash in route? (AngularJS 1.5 + new/component router)
我们正在尝试使用 Angular 1.5 和新的组件路由器位构建一个应用程序。uild。我们 运行 遇到了一些边缘情况，我们想知道是否有任何解决方法。
关键球员
- IdentityServer v2：我们的客户端目前将其用于 OAuth。它导致了这个问题的一部分。它是遗留的，我们无法控制它的使用。
- AngularJS 1.5作为我们的前端框架。
- 新的 angular 路由器 ，我相信现在叫做 ngComponentRouter？我们认为这种风格可以帮助我们在 Angular v1.5 和 Angular v2 之间架起桥梁，而且很容易移植。
- oauth-ng 作为 OAuth 隐式流程的包装器..
- 旧版浏览器：从某种意义上说，我们必须支持 IE9+，这意味着我们不能使用 Angular 的 HTML5 模式。
目标
我们想采用 URL 例如 http://mysite/#!/auth/#auth_token=xyz123（结构不受我们控制，例如不能删除第二个哈希）和：
- 将其放入实际的授权控制器中
- 通过参数或直接通过
$location 获得 auth_token 值。 （它目前在到达控制器之前被擦洗）。
背景/问题
我们的客户有一个中央登录系统，他们在其中使用 IdentityServer v2。据我了解，当我们从 IdSrv v2 请求令牌时，它通过将 #auth_token=xyz123 附加到您的重定向 URL 来响应。当它认为你有 my.com/login.html 时它被写回，从而导致 login.html#auth_token=xyz123.
但是，对于已经使用哈希的 Angular 应用程序，它会成为一个问题，因为 URL 最终会沿着 mysite.com/#/auth#auth_token=xyz123.
行
如您所料，这会让 Angular 生气。我们还没有找到一种方法让它在组件路由器下工作。
它如何与旧路由器一起工作
根据 oauth-ng docs，如果我们使用未启用 html5 的旧路由器，我们将执行如下操作：
angular.module('app').config(function ($routeProvider) {
$routeProvider
.when('/access_token=:accessToken', {
template: '',
controller: function ($location, AccessToken) {
var hash = $location.path().substr(1);
AccessToken.setTokenFromString(hash);
$location.path('/');
$location.replace();
}
})
我们的尝试
- 以类似的方式定义组件路由。这没有用，因为
/access_token=:accessToken 包含一个 =，它似乎没有被组件路由器允许。
- 看看我们能否让 IdentityServer v2 改变响应的格式。这似乎是不可能的；响应似乎被硬编码为
[URL we define]#auth_token=xyz123。
- 使用其他哈希等伪造 URL。通常会导致不良/不一致的行为。
我们认为我们的选择是什么
- 使用万能的/未找到的控制器。如果我们让路由一直下降到
/**，我们可以从 $location 检索令牌值。但这有点恶心；我们想避免它。
- 想办法将完整的 URL 放入控制器。我们可以捕获路由并将其传递给控制器，但此时 URL 不可用。
- 返回使用旧路由器或 ui-路由器（我们此时不希望这样做）。
任何能为我们指明正确方向的信息都将不胜感激！
对此进行跟进：最后，我们认为这是一个足够奇怪的边缘案例，因此有必要返回 ui-router。
虽然我们认为组件路由器最有意义，但这里的决定因素是，不幸的是，我们无法 100% 控制我们的路由。 路由约束包括组件路由器目前似乎无法处理的边缘情况。
对于那些使用较旧的 oauth 服务器系统的人，我希望这会在您选择路由器时作为警告/一些背景。
希望 ngComponentRouter 将来能更好地支持这种边缘情况，尽管我不会责怪他们遗漏它。
我们正在尝试使用 Angular 1.5 和新的组件路由器位构建一个应用程序。uild。我们 运行 遇到了一些边缘情况，我们想知道是否有任何解决方法。
关键球员
- IdentityServer v2：我们的客户端目前将其用于 OAuth。它导致了这个问题的一部分。它是遗留的，我们无法控制它的使用。
- AngularJS 1.5作为我们的前端框架。
- 新的 angular 路由器 ，我相信现在叫做 ngComponentRouter？我们认为这种风格可以帮助我们在 Angular v1.5 和 Angular v2 之间架起桥梁，而且很容易移植。
- oauth-ng 作为 OAuth 隐式流程的包装器..
- 旧版浏览器：从某种意义上说，我们必须支持 IE9+，这意味着我们不能使用 Angular 的 HTML5 模式。
目标
我们想采用 URL 例如 http://mysite/#!/auth/#auth_token=xyz123（结构不受我们控制，例如不能删除第二个哈希）和：
- 将其放入实际的授权控制器中
- 通过参数或直接通过
$location获得 auth_token 值。 （它目前在到达控制器之前被擦洗）。
背景/问题
我们的客户有一个中央登录系统，他们在其中使用 IdentityServer v2。据我了解，当我们从 IdSrv v2 请求令牌时，它通过将 #auth_token=xyz123 附加到您的重定向 URL 来响应。当它认为你有 my.com/login.html 时它被写回，从而导致 login.html#auth_token=xyz123.
但是，对于已经使用哈希的 Angular 应用程序，它会成为一个问题，因为 URL 最终会沿着 mysite.com/#/auth#auth_token=xyz123.
如您所料，这会让 Angular 生气。我们还没有找到一种方法让它在组件路由器下工作。
它如何与旧路由器一起工作
根据 oauth-ng docs，如果我们使用未启用 html5 的旧路由器，我们将执行如下操作：
angular.module('app').config(function ($routeProvider) {
$routeProvider
.when('/access_token=:accessToken', {
template: '',
controller: function ($location, AccessToken) {
var hash = $location.path().substr(1);
AccessToken.setTokenFromString(hash);
$location.path('/');
$location.replace();
}
})
我们的尝试
- 以类似的方式定义组件路由。这没有用，因为
/access_token=:accessToken包含一个=，它似乎没有被组件路由器允许。 - 看看我们能否让 IdentityServer v2 改变响应的格式。这似乎是不可能的；响应似乎被硬编码为
[URL we define]#auth_token=xyz123。 - 使用其他哈希等伪造 URL。通常会导致不良/不一致的行为。
我们认为我们的选择是什么
- 使用万能的/未找到的控制器。如果我们让路由一直下降到
/**，我们可以从$location检索令牌值。但这有点恶心；我们想避免它。 - 想办法将完整的 URL 放入控制器。我们可以捕获路由并将其传递给控制器，但此时 URL 不可用。
- 返回使用旧路由器或 ui-路由器（我们此时不希望这样做）。
任何能为我们指明正确方向的信息都将不胜感激！
对此进行跟进：最后，我们认为这是一个足够奇怪的边缘案例，因此有必要返回 ui-router。
虽然我们认为组件路由器最有意义，但这里的决定因素是，不幸的是，我们无法 100% 控制我们的路由。 路由约束包括组件路由器目前似乎无法处理的边缘情况。
对于那些使用较旧的 oauth 服务器系统的人，我希望这会在您选择路由器时作为警告/一些背景。
希望 ngComponentRouter 将来能更好地支持这种边缘情况，尽管我不会责怪他们遗漏它。