Угловое приложение застряло в бесконечной петле - PullRequest
0 голосов
/ 29 января 2019

У меня есть веб-приложение Angular, которое использует @ microsoft / microsoft-graph-client для получения информации о зарегистрированном пользователе.@ azure / msal-angular используется для входа в систему пользователя.У меня есть служба авторизации, которая регистрирует пользователя с помощью этого:

  async signIn(): Promise<void> {
    const result = await this.msalService.loginPopup(OAuthSettings.consentScopes)
      .catch((reason) => {
        this.alertsService.add('Login failed', JSON.stringify(reason, null, 2));
      });

    if (result) {
      this.authenticated = true;
      await this.getUser();
    }
  }
  private async getClient(): Promise<Client> {
    const graphClient = Client.init({
      // Initialize the Graph client with an auth
      // provider that requests the token from the
      // auth service
      authProvider: async (done) => {
        const token = await this.getAccessToken()
          .catch((reason) => {
            done(reason, null);
          });
        if (token) {
          done(null, token);
        } else {
          done('Could not get an access token', null);
        }
      }
    });
    return graphClient;
  }

private async getUser() {
    if (!this.authenticated) {
      return null;
    }
    const graphClient = await this.getClient();

    // Get the user from Graph (GET /me)
    const graphUser = await graphClient.api('/me').get();

    console.log('USERNAME: ', graphUser.displayName);
    sessionStorage.setItem('d365dataportal.user', graphUser);
    if (graphUser.mail != null) {
      sessionStorage.setItem('d365dataportal.user.email', graphUser.mail);
    } else {
      sessionStorage.setItem('d365dataportal.user.email', graphUser.userPrincipalName);
    }
    sessionStorage.setItem('d365dataportal.user.avatar', graphUser.avatar);
    sessionStorage.setItem('d365dataportal.user.name', graphUser.displayName);
  }

Мои OAuthSettings выглядят так:

export const OAuthSettings = {
  appId: 'App GUID from Azure Here',
  redirectUri: 'http://localhost:4200',
  consentScopes: ['user.read',
    'Directory.Read.All',
    'Directory.ReadWrite.All',
    'Directory.AccessAsUser.All']
};

Проблема, с которой я сталкиваюсь, заключается в том, что при this.msalService.Вызывается loginPopup (), все приложение зависает, всплывающее окно никогда не закрывается и никогда не проверяет подлинность и не перенаправляет обратно на мою страницу.Я не уверен, почему это происходит.Может кто-нибудь увидеть какие-либо явные ошибки?

РЕДАКТИРОВАТЬ

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

Ответы [ 2 ]

0 голосов
/ 01 февраля 2019

Я сделал некоторую отладку и думаю, что есть ошибка или функция, которую я не понимаю в MSAL.Если вы посмотрите на UserAgentApplication.js из библиотеки MSAL, то эта функция называется loginPopupHelper();

Я думаю, что проблема в этом.Если вы посмотрите на this.authorityInstance.ResolveEndpointsAsync() успешную функцию обратного вызова, вы найдете это, если блок

if (popUpWindow) {
    _this._logger.infoPii("Navigated Popup window to:" + urlNavigate);
    popUpWindow.location.href = urlNavigate;
}

Это явно перенаправляет это всплывающее окно на ваш URL перенаправления.И оно никогда не закроет это всплывающее окно, как при сбое обратного вызова.Моим быстрым и грязным решением было изменить его следующим образом:

if (popUpWindow) {
    _this._logger.infoPii("Navigated Popup window to:" + urlNavigate);
    window.location.href = urlNavigate;
    popUpWindow.close();
}

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

Но да, это то, что я смог найти.

РЕДАКТИРОВАТЬ: На самом деле уже есть что-то, связанное сэто в Github.Например

https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/545

https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/479

0 голосов
/ 29 января 2019

Я решил свою проблему, и это не имело никакого отношения к использованию Azure AD или Graph API.В моем html-компоненте у меня был * ngIf, который искал результат функции.Выглядело это так:

<a mat-list-item *ngIf="authService.functionThatReturnsBoolean()" [routerLink]="['/SomeRoute']" routerLinkActive="router-link-active">Link Name</a>

Вместо этого я изменил свой сервис, чтобы заполнить результаты в свойстве сервиса, и указал * ngIf на это свойство следующим образом:

<a mat-list-item *ngIf="authService.booleanProperty" [routerLink]="['/SomeRoute']" routerLinkActive="router-link-active">Link Name</a>

Проблема была связана с тем, как Angular продолжает искать статус в * ngIf.Затем он застрял в том, что казалось бесконечной петлей, пока Chrome не рухнул.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...