2

新しいコンポーネント ルーター ビットを備えた Angular 1.5 を使用してアプリを構築しようとしています。少し特殊なケースに遭遇したので、それを回避する方法があるかどうか疑問に思っています。

主なプレーヤー

  • IdentityServer v2 : 現在、クライアントはこれを OAuth に使用しています。この問題の一部を引き起こします。これはレガシーであり、その使用法を制御することはできません。
  • フロントエンド フレームワークとしてAngularJS 1.5 。
  • ngComponentRouter と呼ばれる新しい angular routerは、今では信じられますか? 私たちは、このスタイルが Angular v1.5 と Angular v2 の間の橋渡しに役立つと考えており、移植も簡単でした。
  • OAuth 暗黙的フローのラッパーとしてのoauth-ng ..
  • 古いブラウザー: IE9+ をサポートする必要があるという意味で、Angular の HTML5 モードを使用できないことを意味します。

目標

次のような URL を取得したいと考えていますhttp://mysite/#!/auth/#auth_token=xyz123(構造は制御下にありません。たとえば、2 番目のハッシュを削除できません)。

  • 実際の認証コントローラーに入れる
  • パラメータを介して、または を介し​​て直接、auth_token 値を使用できるようにします$location。（現在、コントローラーに到達する前にスクラブされています）。

背景・問題点

クライアントには、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-router の使用に戻ります (この時点ではやりたくありません)。

私たちを正しい方向に向けることができるものは何でも大歓迎です！

4

1 に答える 1

1

これをフォローアップするために: 最終的に、これは十分に奇妙なエッジケースであり、 に戻る必要があると判断しましたui-router。

コンポーネント ルーターが最も理にかなっていると考えていますが、ここでの決定要因は、残念ながらルートを 100% 制御できないことです。ルートの制約には、現時点で component-router が処理できないと思われるエッジ ケースが含まれていました。

古い oauth サーバー システムを使用している場合は、ルーターを選択する際に、これが警告または背景として役立つことを願っています。

将来、ngComponentRouter がこのエッジ ケースをより適切にサポートすることを願っていますが、それを省略したことを責めるつもりはありません。

于 2016-04-06T18:57:38.110 に答える