Разрешите запрос $http перед запуском приложения и переключением на маршрут или состояние

Хорошо, после того, как я долго дергал за волосы, вот что я понял.

1. Как и следовало ожидать, resolve — это подходящее место для инициирования любых асинхронных вызовов и обеспечения их завершения до перехода в состояние.
2. Вы захотите создать абстрактное родительское состояние для всех состояний, которое гарантирует, что ваше resolve имеет место, таким образом, если кто-то обновит браузер, ваше асинхронное разрешение все еще будет работать, и ваша аутентификация будет работать правильно. Вы можете использовать свойство parent для state, чтобы создать другое состояние, которое в противном случае не было бы унаследовано путем именования/точечной нотации. Это помогает предотвратить неуправляемость имен ваших состояний.
3. Хотя вы можете внедрить любые службы, которые вам нужны, в свой resolve, вы не можете получить доступ к toState или toStateParams состояния, в которое он пытается перейти. Однако событие $stateChangeStart произойдет до того, как ваше resolve будет разрешено. Итак, вы можете скопировать toState и toStateParams из аргументов события в $rootScope и внедрить $rootScope в свою функцию resolve. Теперь вы можете получить доступ к состоянию и параметрам, к которым он пытается перейти.
4. После того, как вы разрешили свои ресурсы, вы можете использовать промисы для проверки авторизации, и если это не удается, используйте $state.go(), чтобы отправить их на страницу входа, или сделайте все, что вам нужно. Тут, конечно, есть оговорка.
5. Как только resolve будет выполнено в родительском состоянии, ui-router больше не будет разрешать его. Это означает, что ваша проверка безопасности не произойдет! Арх! Решение этой проблемы состоит в том, чтобы иметь двухэтапную проверку. Однажды в resolve, как мы уже говорили. Второй раз в событии $stateChangeStart. Ключевым моментом здесь является проверка и проверка разрешения ресурсов. Если да, выполните ту же проверку безопасности, что и в resolve, но в событии. если ресурс(ы) не разрешен, то проверка в resolve заберет его. Чтобы осуществить это, вам нужно управлять своими ресурсами в службе, чтобы вы могли соответствующим образом управлять состоянием.

Некоторые другие разное. Примечания:

• Не утруждайте себя попытками впихнуть всю логику авторизации в $stateChangeStart. Хотя вы можете предотвратить событие и выполнить асинхронное разрешение (которое эффективно останавливает изменение до тех пор, пока вы не будете готовы), а затем попытаться возобновить изменение состояния в обработчике успеха промиса, есть некоторые проблемы, препятствующие правильной работе.
• Вы не можете изменять состояния в методе onEnter текущего состояния.

Этот планк является рабочим примером.

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

Мы устранили это разделение, поместив вызов $http.get в службу, которая кэширует ответ и немедленно вызывает обратный вызов успеха, если кэш уже заполнен. Например.

app.service('authorizationService', ['authority', function (authority) {
    var requestData = undefined;

    return {
        get: function (successCallback) {
            if (typeof requestData !== 'undefined') {
                successCallback(requestData);
            }
            else {
                $http.get('/svc/account/identity').success(function (data) {
                    requestData = data;
                    successCallback(data);
                });
            }
        }
    };
}]);

Это действует как защита вокруг успешного запроса. Затем вы можете безопасно вызвать authorizationService.get() в обработчике $stateChangeStart.

Этот подход уязвим для состояния гонки, если запрос уже выполняется, когда вызывается authorizationService.get(). Чтобы предотвратить это, можно было бы ввести некоторую бухгалтерию XHR.

В качестве альтернативы вы можете опубликовать пользовательское событие после завершения HTTP-запроса и зарегистрировать подписчика для этого события в обработчике $stateChangeStart. Однако позже вам нужно будет отменить регистрацию этого обработчика, возможно, в обработчике $stateChangeEnd.

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

Кроме того, есть интересное обсуждение аутентификации с помощью ui-router в Как фильтровать маршруты? в группе Google AngularJS.

Я думаю, что более чистый способ справиться с этой ситуацией - это t$urlRouterProvider. deferIntercept() вместе с $urlRouter.listen(), чтобы остановить uiRouter, пока некоторые данные не будут получены с сервера.

См. этот ответ и docs для получения дополнительной информации.