[Proposal] Own AbstractProviders with Custom Configuration

So I quickly put something together which makes it possible to have a fluent interface for the config which at the moment is somewhat clunky in my opinion - https://github.com/SocialiteProviders/StackExchange/issues/2#issuecomment-186761408

These changes would require the following changes to all Providers:

• Provider.php has to extend SocialiteProviders\Manager\OAuth1\AbstractProvider instead of the Laravel\Socialite\One\AbstractProvider
• Provider.php has to extend SocialiteProviders\Manager\OAuth2\AbstractProvider instead of the Laravel\Socialite\Two\AbstractProvider

Additionally we probably also should introduce our own User classes for both OAuth1 and OAuth2 to gain finer control over what is happening and the response data, which you already did for OAuth2.

---

OAuth2/AbstractProvider.php

<?php
namespace SocialiteProviders\Manager\OAuth2;

use GuzzleHttp\ClientInterface;
use Laravel\Socialite\Two\InvalidStateException;
use SocialiteProviders\Manager\SocialiteWasCalled;

abstract class AbstractProvider extends \Laravel\Socialite\Two\AbstractProvider
{
    // all the code of the current AbstractProvider in the OAuth2 folder...

    public function config(array $additionalConfig) {
        $identifier = static::PROVIDER_IDENTIFIER;

        $this->config = array_merge([
            'client_id' => env("{$identifier}_KEY"),
            'client_secret' => env("{$identifier}_SECRET"),
            'redirect' => env("{$identifier}_REDIRECT_URI"),
        ], $additionalConfig);

        return $this;
    }

    protected function getFromConfig($key)
    {
        $identifier = strtolower(static::PROVIDER_IDENTIFIER);

        return app()['config']["services.{$identifier}"][$key];
    }
}

StackExchange/Provider.php

<?php

namespace SocialiteProviders\StackExchange;

use SocialiteProviders\Manager\OAuth2\AbstractProvider;
use SocialiteProviders\Manager\OAuth2\User;
use Laravel\Socialite\Two\ProviderInterface;

/**
 * https://api.stackexchange.com/docs/authentication
 * Class Provider.
 */
class Provider extends AbstractProvider implements ProviderInterface
{
    const PROVIDER_IDENTIFIER = 'STACKEXCHANGE';

    // all the code we have in the Provider.php file of each package at the moment...
}

routes.php

Route::group(['middleware' => ['web']], function () {
    \Route::get('/', function() {
        return \Socialite::with('stackexchange')->config([
            'key' => 'yourkeyfortheservice', 'site' => 'stackoverflow'
        ])->redirect();
    });

    \Route::get('/callback', function () {
        $user = \Socialite::with('stackexchange')->user();

        dd($user);
    });
});

---

If this seems like it goes into the right direction I will finish it up.

Another thing that came to my mind for easier configuration would be that we automatically load the config by parsing the .env file.

.env

STACKEXCHANGE_CLIENT_ID=yourkeyfortheservice
STACKEXCHANGE_CLIENT_SECRET=yoursecretfortheservice
STACKEXCHANGE_REDIRECT_URI=https://homestead.app/callback
STACKEXCHANGE_SITE=stackoverflow

Now we would check which variables start with the PROVIDER_IDENTIFIER and build an array like this for the config.

$config = [
    'client_id' => 'yourkeyfortheservice',
    'client_secret' => 'yoursecretfortheservice',
    'redirect_uri' => 'https://homestead.app/callback',
    'site' => 'stackoverflow',
];

For the array keys we would just need to replace the PROVIDER_IDENTIFIER and cast the string to lowercase.

---

The advantage of this would be that you would just need to change the .env file to get the core and additional configuration setup, no further changes needed.

I have updated all Providers to extend our own AbstractProviders and I will add support for $user->accessTokenResponseBody to the OAuth1 Provider soon.

So once we finished this here up I can quickly push an update for all Providers.

---

Update

With OAuth1 adding the accessTokenResponseBody function seems to get real nasty.

We would need to create our own TokenCredentials and Server classes which have a lot of abstract methods that need to be implemented which means we would have tons of empty methods in these classes just so the Interface is satisfied.

I don't really see a solution as clean as with OAuth2 for OAuth1, maybe you can take a look at this @AndyWendt.

[AndyWendt]

Just saw this :) I will take a look at this in the next couple of days and give it some good thought. This looks like there are some good ideas here :)

At the moment the OAuth1 files look like this. When you look at the Server.php you will see what I mean by those empty methods.

I don't know if there is a better way to add accessTokenResponseBody to the OAuth1 user because the getTokenCredentials-method was the only spot I found where I could snatch in and get the response body.

Twitter/Provider.php

<?php

namespace SocialiteProviders\Twitter;

use League\OAuth1\Client\Credentials\CredentialsException;
use SocialiteProviders\Manager\OAuth1\User;

class Provider extends TwitterAbstractProvider
{
    /**
     * Unique Provider Identifier.
     */
    const PROVIDER_IDENTIFIER = 'TWITTER';

    /**
     * {@inheritdoc}
     */
    protected function mapUserToObject(array $user)
    {
        return (new User())->setRaw($user['extra'])->map(
            [
                'id' => $user['id'],
                'nickname' => $user['nickname'],
                'name' => $user['name'],
                'email' => $user['email'],
                'avatar' => $user['avatar'],
            ]
        );
    }
}

Manager/OAuth1/AbstractProvider.php

<?php

namespace SocialiteProviders\Manager\OAuth1;

use GuzzleHttp\ClientInterface;
use Laravel\Socialite\One\InvalidStateException;
use SocialiteProviders\Manager\ConfigTrait;
use SocialiteProviders\Manager\SocialiteWasCalled;

abstract class AbstractProvider extends \Laravel\Socialite\One\AbstractProvider
{
    use ConfigTrait;

    protected $credentialsResponseBody;

    public static function serviceContainerKey($providerName)
    {
        return SocialiteWasCalled::SERVICE_CONTAINER_PREFIX.$providerName;
    }

    public function user()
    {
        if (!$this->hasNecessaryVerifier()) {
            throw new \InvalidArgumentException('Invalid request. Missing OAuth verifier.');
        }

        $token = $this->getToken();
        $tokenCredentials = $token['tokenCredentials'];

        $user = $this->mapUserToObject((array) $this->server->getUserDetails($tokenCredentials));
        $user->setToken($tokenCredentials->getIdentifier(), $tokenCredentials->getSecret());

        if ($user instanceof User) {
            parse_str($token['credentialsResponseBody'], $credentialsResponseBody);

            if (!$credentialsResponseBody || !is_array($credentialsResponseBody)) {
                throw new CredentialsException('Unable to parse token credentials response.');
            }

            $user->setAccessTokenResponseBody($credentialsResponseBody);
        }

        return $user;
    }

    protected function getToken()
    {
        $temp = $this->request->getSession()->get('oauth.temp');

        return $this->server->getTokenCredentials(
            $temp, $this->request->get('oauth_token'), $this->request->get('oauth_verifier')
        );
    }
}

Manager/OAuth1/Server.php

<?php

namespace SocialiteProviders\Manager\OAuth1;

use GuzzleHttp\Exception\BadResponseException;
use League\OAuth1\Client\Credentials\TemporaryCredentials;
use League\OAuth1\Client\Credentials\TokenCredentials;

class Server extends \League\OAuth1\Client\Server\Server
{
    public function getTokenCredentials(TemporaryCredentials $temporaryCredentials, $temporaryIdentifier, $verifier)
    {
        if ($temporaryIdentifier !== $temporaryCredentials->getIdentifier()) {
            throw new \InvalidArgumentException(
                'Temporary identifier passed back by server does not match that of stored temporary credentials.
                Potential man-in-the-middle.'
            );
        }

        $uri = $this->urlTokenCredentials();
        $bodyParameters = array('oauth_verifier' => $verifier);

        $client = $this->createHttpClient();

        $headers = $this->getHeaders($temporaryCredentials, 'POST', $uri, $bodyParameters);

        try {
            $response = $client->post($uri, $headers, $bodyParameters)->send();
        } catch (BadResponseException $e) {
            return $this->handleTokenCredentialsBadResponse($e);
        }

        return [
            'tokenCredentials' => $this->createTokenCredentials($response->getBody()),
            'credentialsResponseBody' => $response->getBody()
        ];
    }

    /**
     * {@inheritdoc}
     */
    public function urlTemporaryCredentials()
    {
        //
    }

    /**
     * {@inheritdoc}
     */
    public function urlAuthorization()
    {
        //
    }

    /**
     * {@inheritdoc}
     */
    public function urlTokenCredentials()
    {
        //
    }

    /**
     * {@inheritdoc}
     */
    public function urlUserDetails()
    {
        //
    }

    /**
     * {@inheritdoc}
     */
    public function userDetails($data, TokenCredentials $tokenCredentials)
    {
        //
    }

    /**
     * {@inheritdoc}
     */
    public function userUid($data, TokenCredentials $tokenCredentials)
    {
        //
    }

    /**
     * {@inheritdoc}
     */
    public function userEmail($data, TokenCredentials $tokenCredentials)
    {
        //
    }

    /**
     * {@inheritdoc}
     */
    public function userScreenName($data, TokenCredentials $tokenCredentials)
    {
        //
    }
}

@AndyWendt Please take a look at this soon, we have a few Providers which could make good use of this and I want to have this in before I start adding tests to all Providers since it will require some changes.

Don't want to just put it in since the Manager is your package.

[AndyWendt]

I will take a look at it soon. I have a PHP User Group meeting that I need to prepare for tomorrow but after that I should be good.

@AndyWendt Gonna close this soon if no progress is made and might add it as an extra/optional package.

[AndyWendt]

Ok, I will see what I can do here shortly

[AndyWendt]

@DraperStudio working on this today

[AndyWendt]

@DraperStudio you suggested

automatically load the config by parsing the .env file.

What if someone wanted a different config per endpoint (as in Stackexchange)? What if we added an option to parse the config from the .env using a modifier on the facade class?

For example:

// custom config
\Socialite::with('stackexchange')->config($yourCustomConfig)->redirect();

// config from env
\Socialite::with('stackexchange')->configFromEnv()->redirect();

I agree that for different configurations per endpoint people should use the config method and I like the idea of the configFromEnv method.

Should we maybe have the configFromEnv method called by default in the background? Meaning people would only need to enter their details in the .env file and no longer in both the .env and services.php

[AndyWendt]

It does seem unnecessary to have things in the services array, especially when we already know what the keys are going to be. Can you think of any reasons why it would be bad to not use the services array?

It seems like it is an extra step. We could throw an exception if the configuration wasn't found. Our setup is already somewhat complex, it seems, for some people.

I guess since it auto retrieves from the services array already, why not from the .env?

[AndyWendt]

I added a waffle board for issues here: https://waffle.io/SocialiteProviders/Manager