Defer configuration loading in dedicated method instead of controller

#1090 Library

• msal@1.x.x or @azure/msal@1.x.x
• @azure/msal-browser@2.x.x
• @azure/msal-angular@0.x.x
• @azure/msal-angular@1.x.x
• @azure/msal-angularjs@1.x.x

Description

Hi everyone, In my situation, I need to load oidc configuration from a remote server, so I need to make an http call to retrieve it. I have read all the docs and tryed all the ways to load configurations but nothing suits my need and I think I won’t be the only one looking for this. I am working on a security library which will be embedded in many other project, the goal is to obfuscate any auth security process within this lib which will expose only basic methods to hosts projects. The libs needs then to handle all Msal init (service instanciation, interceptors, etc) and retrieve the config url via an injection token injected by host app.

The only way to load asynchronously a config file from doc is to use platformDynamic, but I don’t want to duplicate that Msal specific configuration scheme in all the applications that will use the library. Also the APP_INITIALIZER provider is not delaying the app bootstrap so the configuration is not loaded on time because MsalService load configuration in constructor.

What I needed to do is to build a custom wrapper service to handle remote configuration loading and manual MsalService instanciation (loading config from constructor). Then set a flag init to true, and use my inner MsalService instance.

It would be nice to have a configure(config) method to be able to manage the lib initilization flow entirely. Instead of init in constructor.

Here is the code I made to have an idea, I would be able to make a PR if you think it is interesting.

@Injectable({
  providedIn: 'root'
})
export class ConfigService {
  public msalService: MsalService;
  private http: HttpClient;
  public configInit = new Subject();
  constructor(httpClient: HttpClient, private router: Router, private broadcasService: BroadcastService) {
    this.http = httpClient;
  }

  configure(uri) {
    this.http.get(uri).pipe(map(res => res))
    .subscribe((value: any) => {
      msalConfig.auth.clientId = value.client_id;
      msalConfig.auth.postLogoutRedirectUri = value.post_logout_redirect_uri;
      msalConfig.auth.redirectUri = value.redirect_url;
      msalConfig.auth.authority = value.stsServer;
      msalAngularConfig.consentScopes = value.scope.split(" ");
      this.msalService = new MsalService(msalConfig, msalAngularConfig, this.router, this.broadcasService);
      this.configInit.next(true);
    },
      (error) => {
      });
  }
}

[ozkoidi]

Hello @Depechie,

They may have fixed the issue in the meantime but in case it helps you, the workaround that worked for me is the following:

Disable the initial navigation in the routing module

@NgModule({
  imports: [
    RouterModule.forRoot(ROUTES, {
      initialNavigation: 'disabled'
    })
  ],

In app.module.ts pass the Router to the initializer method

...
providers: [
  ...,
  {
    provide: APP_INITIALIZER,
    useFactory: initializeApp,
    deps: [Router],
    multi: true
  },
  ...

to call router.initialNavigation(); after reading the configuration file

  export const initializeApp = (router: Router) => async () => {
    await config.load(); <- This is where you load the config file
    router.initialNavigation(); <- This enables the navigation we disabled in the routing module
  };

[jasonnutter]

We will look to support updating the MSAL configuration dynamically in MSAL Angular v2 (alpha available now).