connector-basic plugin bypass binding with an activation email

[lzf-tech]

Is your enhancement request related to a problem? Please describe

NO

Describe the solution you'd like

how can the connector-basic plugin be configured to bypass binding with an activation email and instead allow users to use OAuth2 verification as their identifier for direct access?

Describe alternatives you've considered

None

[LinkinStars]

@lzf-tech FYI: https://github.com/apache/incubator-answer-plugins/tree/main/connector-basic#how-to-config

You can configure the User Email JSON Path and Check Email Verified to solve it. For example, if you are using the Google OAuth, you can set the Check Email Verified to email_verified. After that, when the user login from Google, if Google returns the email_verified=true means this user's email does not need to be active again.

[shockdm]

Thank you for the response @LinkinStars. Furthermore what if OAuth provider doesn't return email_verified value? I.e. organizational OAuth, where the verification status is implied.

[shockdm]

Specifically, when logging in with oauth provider getting presented with:

Is there a way to avoid this w/o having email_verified=true on oauth response?

Update, looking at https://github.com/apache/answer-plugins/blob/main/connector-basic/basic.go it appears there isn't but seems like it would be a good option to offer for clients who's OAuth emails are implicitly verified. Would it be acceptable to offer such an option? I can draft up a PR quickly if so.

[LinkinStars]

Specifically, when logging in with oauth provider getting presented with:

Is there a way to avoid this w/o having email_verified=true on oauth response?

Update, looking at https://github.com/apache/answer-plugins/blob/main/connector-basic/basic.go it appears there isn't but seems like it would be a good option to offer for clients who's OAuth emails are implicitly verified. Would it be acceptable to offer such an option? I can draft up a PR quickly if so.

@shockdm

Let me clarify. There are three configurations

1. User Email JSON Path: Path in the OAuth2 User JSON to the user email. eg: user.email
2. Check Email Verified: If set to true, the email will be verified by email_verified_json_path. If not, the email is always believed to have been verified.
3. Email Verified JSON Path: Path in the OAuth2 User JSON to the email verified. eg: user.email_verified

If the Check Email Verified option is set to true, it will verify the email. If it is set to false, it will not verify the email.

That is, if Check Email Verified is set to false, as long as the third party provides the email address in the json according to the User Email JSON Path, there is no need to verify. If there is a validation, such as your screenshot, it is obvious that the email is not provided.