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

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

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

  • 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 (структура не находится под нашим контролем, например, мы не можем удалить второй хэш) и:

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

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


angularjs identityserver2 thinktecture-ident-server angular-new-router ngcomponentrouter
person SeanKilleen    schedule 01.03.2016    source источник
comment
Это может быть не по теме, но вы, ребята, пробовали ui-router?   -  person Kudos    schedule 02.03.2016
comment
@adeel_s мы выбрали новый компонентный маршрутизатор вместо ui-router для этого процесса по другим причинам, связанным с этим проектом, поэтому, к сожалению, на данный момент это невозможно.   -  person SeanKilleen    schedule 02.03.2016

Ответы (1)


arrow_upward
1
arrow_downward

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

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

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

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

person SeanKilleen    schedule 06.04.2016