Skip to content
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

Merged

Conversation

kyubisation
Copy link
Contributor

This PR adds a feature withAppInitializerAuthCheck to handle OAuth callbacks during app initialization phase. This replaces the need to manually call OidcSecurityService.checkAuth(...) or OidcSecurityService.checkAuthMultiple(...).

Closes #1926

@FabianGosebrink
Copy link
Collaborator

Thanks, that is a nice idea. Love it. This would also mean that we have to update the samples, is this correct?

@kyubisation
Copy link
Contributor Author

Thank you 😃
As it is an opt-in, I was not sure how deep to integrate it into existing code. Is there a specific example or range of examples where you would like to see this used?

@FabianGosebrink
Copy link
Collaborator

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 checkAuth(...) step, which gets forgotten really easily. However, maybe we can enhance an existing sample "sample-code-flow-azuread" or "sample-code-flow-auth0", comment out the added code and comment it like you did on the docs, so that the users can see what they would have to change. What do you think?

@kyubisation
Copy link
Contributor Author

I think that's fine. 👍
I'm also fine with creating a new example, if that is preferred.
I'll have a look to adapt this, but it might be next week.

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.

@FabianGosebrink
Copy link
Collaborator

FabianGosebrink commented Sep 20, 2024

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?

@kyubisation
Copy link
Contributor Author

That sounds reasonable. 👍
And yes, I am unfortunately very much aware of the many ways auth can be used (and misused).

No, not at the moment, but that statement might be misleading.
We previously used the keycloak library or https://www.npmjs.com/package/angular-oauth2-oidc. This year we evaluated this library (and others), with the result that this library matches our use case the best.
Due to this, it is now the recommended authentication library for new projects. but that does not affect our hundreds of existing Angular applications that might or might not migrate the auth library.
I hope that puts it into perspective.

@FabianGosebrink
Copy link
Collaborator

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

  • enhance one sample with the new way commented out
  • add docs to have the "old" and "new" way side by side or underneath, so that we can link to it

Your PR is awesome. Thanks so much.

@kyubisation
Copy link
Contributor Author

@FabianGosebrink I just realized that currently the only example using provideAuth is the sample-code-flow-standalone. Should I enhance that example or should e.g. the azuread example be migrated to standalone?

Copy link
Contributor

@timdeschryver timdeschryver left a 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.

@kyubisation
Copy link
Contributor Author

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.
Feel free to have another look and tell me, if I still need to address something.

Copy link
Contributor

@timdeschryver timdeschryver left a 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".

Comment on lines +244 to +265
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}'`);
});
}
...
```
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

@timdeschryver timdeschryver Oct 2, 2024

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.

Copy link
Contributor Author

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?

Copy link
Contributor

@timdeschryver timdeschryver Oct 3, 2024

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 :)

Copy link
Collaborator

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 :)

@FabianGosebrink
Copy link
Collaborator

Thank you both for being so active here :)

@FabianGosebrink
Copy link
Collaborator

@timdeschryver are you okay with merging this?
@kyubisation You finished with implementing this?

@kyubisation
Copy link
Contributor Author

Yes, I was merely waiting for any advice on how to proceed with the raised issue.
If it is fine, as it is, it can be merged. If I should adapt the documentation, I can do that if desired.

Copy link
Contributor

@timdeschryver timdeschryver left a 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

@FabianGosebrink FabianGosebrink merged commit 14f032c into damienbod:main Oct 9, 2024
9 checks passed
@FabianGosebrink
Copy link
Collaborator

Thanks :)

@kyubisation kyubisation deleted the feat-app-initializer-auth-check branch October 9, 2024 18:23
@kyubisation
Copy link
Contributor Author

Thank you both for the review, feedback and merge. 😃 👍

@FabianGosebrink
Copy link
Collaborator

Thank YOU for the work you did!! This lib grows because of contributions from people like you. You did amazing. Thanks a million!

@konstantinvlasenko
Copy link

konstantinvlasenko commented Oct 10, 2024

Question. I am using 18.0.1
I don't see withAppInitializerAuthCheck
Am I missing something?

Trying to run this example https://github.com/damienbod/angular-auth-oidc-client/tree/main/projects/sample-code-flow-azuread
But getting error TS2305: Module '"angular-auth-oidc-client"' has no exported member 'withAppInitializerAuthCheck'

@kyubisation
Copy link
Contributor Author

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.

@FabianGosebrink
Copy link
Collaborator

Yes, we will run the last tests and then release with this feature included. Thanks!

@damienbod
Copy link
Owner

I will do some testing, docs and try to release this weekend

Greetings and thanks for the PR, Damien

@goncard
Copy link

goncard commented Oct 11, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Feature Request]: Option for authCheck during app initialization phase
6 participants