Adding dynamic values for auth module forRoot() configuration
See original GitHub issueIssue type
I’m submitting a … (check one with “x”)
- bug report
- feature request
Issue description
Current behaviour: Hi team, happy new year!
We’re currently implementing a continuous integration/deployment pipeline for the Angular app from our local dev to Azure test and production web app slots, and we’ve hit an Ahead of Time compilation challenge.
With JIT compilation we’ve been defining the callback URL for the auth configuration using document.getElementsByTagName('base')[0].href + 'auth/callback'
- which has meant between different deployment slots, the URL has been updated dynamically. However, this method does not work with AoT compilation which we need to now enable in our production & test scenarios, as the window element doesn’t exist when it compiles.
We’ve implemented a configuration API in our ASP.NET Core server that’s called when the Angular app is initialised utilising the APPINITIALIZER injection token (https://elanderson.net/2018/05/pass-asp-net-core-appsettings-values-to-angular-via-an-api-call/); this works great for most of the configuration we provide throughout the app as when components are initialised we can get config values from the ConfigService, and this means our server can provide different values depending on the hosting environment, without having to rebuild the app.
The problem we’ve got is because Nebular auth config is provided in a module decorator as static values:
...NbAuthModule.forRoot({
strategies: [
AzureADB2CAuthStrategy.setup({
name: 'AzureADB2C',
clientId: environment.azureADB2C.clientId,
clientSecret: '',
authorize: {
endpoint: environment.azureADB2C.endpoint,
responseType: 'id_token',
scope: environment.azureADB2C.scope,
redirectUri: environment.azureADB2C.callbackURL, // was document.getElementsByTagName('base')[0].href + 'auth/callback'
params: {
'p': environment.azureADB2C.policyName
}
},
token: {
class: AuthAzureToken,
},
redirect: {
success: '/dashboard/overview',
},
}),
],
And any attempt I’ve tried to inject the configuration into this that was retrieved by APPINITIALIZER configservice has failed; it seems that the decorators are precompiled and therefore any dynamic values retrieved at runtime can’t be inserted into this, always returning null.
We’re having to stick with using the static const environment files at the moment and do separate builds for each environment with the different callback URLs and other auth config hardcoded.
Expected behaviour: We would like to be able to provide the Nebular auth configuration dynamically at runtime in a different method than a static forRoot declaration - providing all of these sensitive values in the angular application code doesn’t seem to be very production ready or secure. Or any other suggestions of ways around this would be welcome!
Steps to reproduce:
Use the ngx-admin template, serve it from a dotnet core server then follow https://elanderson.net/2018/05/pass-asp-net-core-appsettings-values-to-angular-via-an-api-call/ - trying to take the configuration retrieved from the APPINITIALIZER and supplant it into ngAuthModule.forRoot({ ... })
Angular, Nebular
Angular 7.1.4
Nebular 3.0.1
Issue Analytics
- State:
- Created 5 years ago
- Reactions:12
- Comments:16 (4 by maintainers)
Top GitHub Comments
Thanks @nnixaa and @myleshk for sharing some insights here - we redirect to our oauth provider on router guard when initially loading the app if the user isn’t authenticated, so I assume I’d need to setOptions in the router-guard and overwrite the ones set in the module. I can imagine this will get quite fragmented if we need to overwrite the app.module.ts forRoot() configuration each time with dynamic values at the component level (there are various places where a user could sign in/out etc.), so would be much more workable if we can declare these dynamic variables forRoot() globally in the app module
@nnixaa I know it’s been 3 years almost since this was posted, but is there any way we can provide these values dynamically today? The examples above do not work in the latest version (v8).
Interesting that this was marked as “Nice to have” but it is actually essential when working with CI tools and have multiple environments. Build once, deploy to all.