-
Notifications
You must be signed in to change notification settings - Fork 434
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add withAppInitializerAuthCheck
as a feature for provideAuth
#2006
feat: add withAppInitializerAuthCheck
as a feature for provideAuth
#2006
Conversation
Thanks, that is a nice idea. Love it. This would also mean that we have to update the samples, is this correct? |
Thank you 😃 |
We have to thank YOU for this PR ❤️ It would be nice to see the either/or comparison in the docs, because the users have to erase the |
I think that's fine. 👍 Maybe one question is; Should this potentially become the recommendation (in examples) in the future? While we at SBB have been using this approach for a while, I am hesitant to suggest a change in the general approach, as I am not a maintainer of this project. We can also wait a while before evaluating whether a change would be an improvement. |
Generally: Yes, I would recommend this. In practice and out of experience, I know that auth and so also this lib is used in ways you can not even imagine. So if it fits for EVERY case? I doubt it, because auth is very special. However, we want to provide a go to and fast solution to do your auth, so your feature is self explaining and with the docs we can also advise for the alternative solution. If we see that your feature establishes as stable, when can absolutely take it as the recommended solution. I, personally, will absolutely use it that way :) Next week is absolutely fine, as you like, and I would not create an extra sample for this. Are you using it heavy at the SBB? |
That sounds reasonable. 👍 No, not at the moment, but that statement might be misleading. |
Hey, thanks. Yeah, that is what I also see at customer projects. New project use the new guidelines, and old ones might or might not be migrated. Nice. Let me know if you are missing any feature, have a question or need something. We leave this PR for now and
Your PR is awesome. Thanks so much. |
@FabianGosebrink I just realized that currently the only example using |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this feature!
I think updating the standalone example is fine for now, as we can use it to verify that this feature works as expected.
With standalone becoming the default I think we should update all examples in seperate PR(s).
We can leave one using NgModule
to also cover.
I suppose the docs will need some enhancements too.
docs/site/angular-auth-oidc-client/docs/documentation/configuration.md
Outdated
Show resolved
Hide resolved
bce9443
to
49a71ee
Compare
I have migrated the azuread example, as this leaves an example with the current/previous standalone configuration. I have also extended the documentation a little bit, as discussed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
The comment is a personal one, but isn't "blocking".
If you prefer to manually check OAuth callback state, you can omit | ||
`withAppInitializerAuthCheck`. However, you then need to call | ||
`OidcSecurityService.checkAuth(...)` or | ||
`OidcSecurityService.checkAuthMultiple(...)` manually in your | ||
`app.component.ts` (or a similar code path that is called early in your app). | ||
|
||
```ts | ||
// Shortened for brevity | ||
... | ||
export class AppComponent implements OnInit { | ||
private readonly oidcSecurityService = inject(OidcSecurityService); | ||
|
||
ngOnInit(): void { | ||
this.oidcSecurityService | ||
.checkAuth() | ||
.subscribe(({ isAuthenticated, accessToken }) => { | ||
console.log('app authenticated', isAuthenticated); | ||
console.log(`Current access token is '${accessToken}'`); | ||
}); | ||
} | ||
... | ||
``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can also refer to the checkAuth
API, this keeps the documentation in one place.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you explain this in more detail? I'm not sure I fully understand what you mean.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The docs already provide information and an example for checkAuth
and checkAuthMultiple
.
This means we can (in my opinion) just refer to the documentation, instead of including it here.
This prevents duplicates and makes it easier to change/update the docs later.
We can remove this section and update the text above the example, something as:
Additionally, you can use the feature function `withAppInitializerAuthCheck`
to handle OAuth callbacks during app initialization phase.
This replaces the need to manually call [`OidcSecurityService.checkAuth(...)`](/docs/documentation/public-api#checkauthurl-string-configid-string) or
[`OidcSecurityService.checkAuthMultiple(...)`](/docs/documentation/public-api#checkauthmultipleurl-string) within the `app.component.ts` file (or a similar code path that is called early in your app).
As a result we don't repeat ourselves.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can do that, but @FabianGosebrink requested to add docs to have the "old" and "new" way side by side or underneath, so that we can link to it
.
I'm fine with either. Should I adapt, as suggested by @timdeschryver?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh nevermind my comment then :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Easy, I just wanted it to make it as easy as possible for the users to use. I am fine with both :)
Thank you both for being so active here :) |
@timdeschryver are you okay with merging this? |
Yes, I was merely waiting for any advice on how to proceed with the raised issue. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me
Thanks :) |
Thank you both for the review, feedback and merge. 😃 👍 |
Thank YOU for the work you did!! This lib grows because of contributions from people like you. You did amazing. Thanks a million! |
Question. I am using 18.0.1 Trying to run this example https://github.com/damienbod/angular-auth-oidc-client/tree/main/projects/sample-code-flow-azuread |
This feature has not been released yet. I am not overly familiar with the release cycles of this library, but I assume this will be released with version 19 in November. |
Yes, we will run the last tests and then release with this feature included. Thanks! |
I will do some testing, docs and try to release this weekend Greetings and thanks for the PR, Damien |
Question: when we are guarding all the routes with AutoLoginPartialRoutesGuard, will this feature replace the need to call checkAuth on app component or callback component? I am calling it on the callback component which is my public route but if it will not be needed anymore, the callback component will basically be useless. Does it make sense to keep a empty component? What would you do in this case? Thanks. |
This PR adds a feature
withAppInitializerAuthCheck
to handle OAuth callbacks during app initialization phase. This replaces the need to manually callOidcSecurityService.checkAuth(...)
orOidcSecurityService.checkAuthMultiple(...)
.Closes #1926