Как бороться с лишним хешем в маршруте? (AngularJS 1.5 + новый / компонентный маршрутизатор)

Question

Мы пытаемся создать приложение с использованием Angular 1.5 с новыми битами компонентного маршрутизатора. Мы натолкнулись на крайний случай, и нам интересно, есть ли способ обойти это.

Ключевые игроки

• IdentityServer v2: наш клиент в настоящее время использует это для OAuth. Это вызывает часть этой проблемы. Это наследие, и мы не можем контролировать его использование.
• AngularJS 1.5 в качестве нашего внешнего интерфейса.
• Я полагаю, что новый угловой маршрутизатор, называемый ngComponentRouter? Мы полагали, что этот стиль поможет нам соединить Angular v1.5 и Angular v2, и портировать его было достаточно просто.
• oauth-ng в качестве оболочки для нашего неявного потока OAuth.
• Старые браузеры: в том смысле, что мы должны поддерживать IE9+, что означает, что мы не можем использовать режим Angular HTML5.

Цель

Мы хотели бы взять URL-адрес, такой как http://mysite/#!/auth/#auth_token=xyz123 (структура не находится под нашим контролем, например, не может удалить второй хэш) и:

• Получите его в настоящий контроллер аутентификации
• Иметь значение 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, если бы мы использовали старый маршрутизатор без включенного 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-маршрутизатора (чего мы не хотели бы делать в этот момент).

Все, что может указать нам правильное направление, будет с благодарностью!

Answer 1

Чтобы продолжить это: в конце концов, мы решили, что это достаточно странный крайний случай, который оправдывает возвращение к ui-router,

Хотя мы считаем, что компонентный маршрутизатор имеет наибольшее значение, решающим фактором является то, что, к сожалению, мы не имеем 100% контроля над нашими маршрутами. Ограничение маршрута включало пограничный случай, который компонент-маршрутизатор не мог обработать в настоящее время.

Для тех, кто работает со старыми системами oauth-серверов, я надеюсь, что это послужит предупреждением / некоторым фоном при выборе маршрутизатора.

Надеемся, что ngComponentRouter лучше поддержит этот крайний случай в будущем, хотя я бы не стал винить их за то, что он его пропустил.