Skip to content

Add more control over on the user creation for users that doesn't already exist in the users collection #39

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

Open
yaronuliel opened this issue Apr 24, 2025 · 2 comments

Comments

@yaronuliel
Copy link

When a user pass the authentication level, while it doesn't exist in the users collection - currently the plugin creates a new user in the collection without much control (aside from the collection config)

It would be great if we could completely disable the missing user create via plugin config (sometimes authorization is fully managed inside the app, while only the authentication step is manages in the external identity provider).

Also, it would make sense to be able to pass a callback function that receives the JWTUser object and returns the properties of the new user to create (while returning null means - don't create user or something like that)

@WilsonLe
Copy link
Owner

WilsonLe commented May 8, 2025

Also, it would make sense to be able to pass a callback function that receives the JWTUser object and returns the properties of the new user to create (while returning null means - don't create user or something like that)

Maybe I misunderstood but isn't that's what the configurable getUserInfo does?

@WilsonLe WilsonLe linked a pull request May 8, 2025 that will close this issue
@WilsonLe WilsonLe removed a link to a pull request May 8, 2025
@yaronuliel
Copy link
Author

Also, it would make sense to be able to pass a callback function that receives the JWTUser object and returns the properties of the new user to create (while returning null means - don't create user or something like that)

Maybe I misunderstood but isn't that's what the configurable getUserInfo does?

getUserInfo is used as a way to extract information from accessToken (which requires additional, IDP specific work) - while in my suggestion - you should take the already extracted information from the accessToken and be able to massage it before it is being stored on the user.
My suggestion also adds the important ability to cancel the login process / user search by returning NULL. in some cases you might want the process to stop due to internal system configuration though the external login passed successfuly - (authentication vs authorization)

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

No branches or pull requests

2 participants