Dispatch events for handling authentication errors in provider

This looks like a valid thing to add. However, I wonder if this problem could not be solved by using events instead.

If we are to include something like this, we might want to allow options to redirect to the origin in successful or failed logins. Something that is more general. What do you think about allowing this to be the case?

By the way, we might want to include these as options in the settings form then

Sorry, I think I'm not getting your point correctly.

to add settings to allow user to redirect back to origin page when destination is used

Are you saying that we need to provide a way to allow the destination parameter to be set to the origin?

For instance, the user is at /node/5 and tries to log in. Then, the destination would be set to /node/5

Two things here:

1. What about dispatching an event on authentication error? Implementers usually check that there are no errors in their callback methods. We can define a dispatchAuthenticationError method in Social Auth and call it in these cases. This will give the developer more flexibility in determining what exactly to do in a failed login.
2. If we decide not to do the event approach, I would suggest a common method to handle login_destination and login_error_destination. I would like things to be as simple as possible in the implementer's side.

1. +++ b/src/Controller/OAuth2ControllerBase.php
   @@ -112,6 +125,7 @@ class OAuth2ControllerBase extends ControllerBase {
   +                              EventDispatcherInterface $event_dispatcher,
   

   I'm concerned that this will break everything. We need backward compatibility as we did with $renderer.

2. +++ b/src/Event/SocialAuthProviderEvent.php
   @@ -0,0 +1,92 @@
   +class socialAuthProviderEvent extends Event {
   

   Maybe ProviderRedirectEvent. Let's try to get rid of the SocialAuth prefix in most of our classes.

3. +++ b/src/Event/SocialAuthProviderEvent.php
   @@ -0,0 +1,92 @@
   +  /**
   +   * Store error destination path where user should redirect when provider
   +   * Throws error.
   +   *
   +   * @param string $error_destination
   +   */
   +  public function setErrorDestination($error_destination) {
   +    $this->dataHandler->set('login_error_destination', $error_destination);
   +  }
   

   Do we need this? I wonder if the event listener can't just do the redirection if there's an error in provider.

I'm concerned that this will break everything. We need backward compatibility as we did with $renderer.

Another way to go about might be to use userAuthenticator to handle the error dispatching. This object already contains the event dispatcher

Thanks!

+++ b/src/Controller/OAuth2ControllerBase.php
@@ -212,6 +230,25 @@ class OAuth2ControllerBase extends ControllerBase {
+  public function dispatchAuthenticationError($error = NULL) {
+    $event_object = new ProviderErrorEvent($this->dataHandler, $this->pluginId, $error ?? NULL);
+    $this->eventDispatcher->dispatch(SocialAuthEvents::PROVIDER_ERROR, $event_object);
+
+    if ($event_object->hasResponse()) {
+      return $event_object->getResponse();
+    }
+    return NULL;
+  }

The class has the object protected, it will require a public helper method to use it outside the class.
Instead, I think we should inject the dependency inside OAuth2ControllerBase itself as optional, and if not passed, we'll use the service like the $renderer.

Why can't this code be in UserAuthenticator? Injecting the event dispatcher service is a pain for two reasons. First, we'll need to update all implementers. Second, I think it feels more natural to just have it in UserAuthenticator since it is an error with authentication.

Of course, doing so wouldn't allow us to dispatch an event before redirecting, but I'm not sure why you would need one. Any thoughts?

The other option is to have a getEventDispatcher in UserAuthenticator, so we can dispatch an event before redirecting without injecting the service.

Would you mind sharing an interdiff? Also, some documentation would be nice for this issue. We can create a new doc page for 'Handling authentication errors' or something similar, like this page.

Please add a new documentation page under the Social Auth documentation guide. This will also help me test the changes and we'll have documentation for this. Even if we decide to change some parts of your patch, I believe the new events would work anyways.

Thank you for working on this! I would love to include it in the next release

I made a few changes regarding the events' names and constants. I also updated the documention and will add the example in social_api_examples.

Thank you so much! This was an awesome job!