Should the strategy be responsible of validating the "hd" attribute?

[nicolasblanco]

Hello folks.

In the README it's written:

the hd parameter to suggest a particular Google Apps hosted domain (caution, can still be overridden by the user)

If I look at the Ruby Google OAuth2 Omniauth strategy (Ueberauth philosophy is based on Omniauth for people who don't know), we can see that the strategy is validating the hd parameter during the callback phase and raising an exception if the domain is invalid:
https://github.com/zquestz/omniauth-google-oauth2/blob/master/lib/omniauth/strategies/google_oauth2.rb#L213

So my question is: do you think this strategy should also validate the hd parameter like the Ruby one?
Would you accept a PR which would implement such behaviour?

Thanks!

[Hanspagh]

Sorry for the delay on this, but I think this would be great 👍

[greg-rychlewski]

Hi,

I was taking a look at implementing this and noticed something about the way Omniauth does things. They seem to be using the hd parameter as a way of validating the allowed domains, even going so far as to allow the parameter to be an array.

As far as I can tell from the google documentation , the hd parameter is meant to customize the UI for a particular domain and should be a string that is either a single domain or an asterisk (for generic G Suite accounts).

What would you think about allowing another provider option called allowed_hd that could be one of the following:

1. a single string representing the only allowed domain
2. a list of strings representing multiple allowed domains

Then the hd value sent back by the token could be validated if this option was specified. If the option is not specified then any domain is allowed.