-
Notifications
You must be signed in to change notification settings - Fork 17
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
Google: extended hd
whitelisting support
#16
Comments
Please submit a PR against GoogleProvider for now. |
Any comment on upstream PR? |
Up. Since upstream considered this to be up to library's consumers, could you please reconsider? |
ping |
Is there a PR to review? |
@drzraf What is the status of this one? |
If you feel that upstream rejection means it'd be adequate to do it within |
If it was rejected, we shouldn't add the feature. But that said, if they figured out another method to add it, I'm not against adding the support. |
They didn't reject the feature per-se but the implementation. I manage the GSuite for an organization which have multiple domains and users belonging to these domains. Without a patch I can't offer cross-domain logging (whitelisting more than one domain) |
hd
parameters allow to limit allowed users to those belonging to one specific GSuite domain (other values like*
orunset
allow every user).This is done by
vendor/league/oauth2-google/src/Provider/Google.php::assertMatchingDomain()
which is the last instruction done before
Provider::getResourceOwner()
returns.This is not as flexible as possible as it may be desirable to provide whitelisted domains either as a list or a regexp, ...
A flexible and future-proof solution would be to simply allow user-provided function to define this behavior (taking OIDC user-data as parameters and returning a boolean about whether user is accepted).
Do you think there could be room, either in
BaseProvider.php
orGoogleProvider.php
for such an improvement?The text was updated successfully, but these errors were encountered: