An attempt to make this package PHP7.2+ compatible, featuring the latest versions of its dependencies as possible.

• Cleaned up (without any change to logic, but with minor implementation fixes) the codebase making it PHP7 and PSR0 compat.
• Updated the tests in a very minor way, to reflect return-type expectations to align with Guzzle-7 classes
• Updated Travis-CI flow: disabled Scrutinizer as it somehow doesn't work with PHP7, which can be fixed later
• Added Docker Compose setup for development purposes which features OOTB Xdebug setup (port 54321, ideKey=basisPhp). Container used is from another OS project of mine, but can be replaced later on, when something specific to this project or League gets created.
• Updated composer dependencies to the latest version (as possible).
• Dropped PHP-CodeSniffer in favor of Php-Cs-Fixer. Maybe later Psalm can be added, when typing issues are completely resolved.

Expectations from this PR:

• To have a 2.0 release with PHP7.2+ only support.

Further notes:

• Recommend to refactor existing "Version-2" branch on top of this one, for possible 3.0 release.
• Although Guzzle-7 works fine in this PR, in future, PSR-18 implementation should be brought forward to decouple from Guzzle.
• Some online coverage service should be added as part of CI. Scrutinizer is really behind (I used it in past as well, in my other projects)

The following PHP warning is generated under PHP 8:

League/OAuth1/Client/Signature/HmacSha1Signature::League/OAuth1/Client/Signature/{closure}(): 
Argument #2 ($value) must be passed by reference, value given in 
/vendor/league/oauth1-client/src/Signature/EncodesUrl.php on line 54

Seems to be caused by the second parameter being passed as a reference. Removing the '&' symbol from value seems to work for me, but I don't know if there are greater implications outside of my particular use case.

laravel/socialite and others depending on this package display

Package guzzle/guzzle is abandoned, you should avoid using it. Use guzzlehttp/guzzle instead.

so I've update the guzzle dependency.

Tests seem to run just fine

gabriel@~:oauth1-client (git:master) $ phpunit
PHPUnit 4.8.26 by Sebastian Bergmann and contributors.
Warning:    The Xdebug extension is not loaded
        No code coverage will be generated.

.....................................

Time: 212 ms, Memory: 8.75MB

OK (37 tests, 114 assertions)

Hi all! I'm not sure what's considered the public API of this package, but the most recent update has broken the socialiteproviders/providers package which allows social logins in Laravel. It'll also have broken any custom OAuth providers which extend the League\OAuth1\Client\Server\Server class, due to the typehinting of the methods.

In this particular case, it's made more problematic by the fact that Laravel socialite defines its own user to return, so the typehintinh for getUserDetails cannot be met without changes in several repositories.

Was this release meant as a minor release, or should it be upgraded to a major to stop any existing extensions being broken?

This PR serves as the basis for an entire rewrite of this package. The previous version has been around for a very long time and is quite long in the tooth.

Key improvements over the older version are:

1. The overall architecture in the older version leads to a lot of duplication in tests and our tests are in fact often not really testing anything meaningful.
2. After re-reading the spec, there are a couple of areas where we currently don't correctly address creating an OAuth signature. Obviously this works for most folks, however there's some edge cases which we don't account for. Upon searching the web for other OAuth 1 packages, it appears nobody (that I've seen) accounts for these. An example is where the same parameter is found in both the request body and the query string. Both instances should be used for generating the OAuth signature. The new version accounts for this.
3. The creation of additional providers which customise functionality was painful in the previous iteration. By utilising PSR-7, PSR-17 and PSR-18, providers have a lot more flexibility to setup unique requests if they need to instead of overriding a lot of functionality.
4. Again, with the addition of PSR, we have decoupled from requiring specific Guzzle versions. We suggest Guzzle as a perfect partner for this package, however our only dependency is an implementation of the relevant PSRs as well as a Guzzle support package for handling RFC 3986 encoding/decoding. The final iteration of this package may remove that dependency.
5. The rewrite express a Generic Provider, which any OAuth1-compliant server should work with. We will likely remove all additional providers by extracting them into external packages (up for debate) and supply only the Generic Provider out of the box.
6. The rewrite has extensive unit test coverage with many scenarios in key areas, such as signature generation and OAuth flow. We have taken examples right out the OAuth spec and plugged them into our tests to ensure that we catch the edge cases exposed by the spec. We also have 100% code coverage, obviously 😉.

To do:

• [ ] Decide if we extract providers out and ship with only a Generic Provider, or do we ship with the same providers as the old version? Thoughts: maybe we ship with the most common ones. Some less common ones like Magento 1 introduce the requirement of XML-based PHP extensions being dependencies…
• [ ] Write up detailed documentation with usage examples.
• [ ] Add a handy Guzzle middleware to sign authenticated OAuth 1 requests, or recommend the usage of the official OAuth subscriber.
• [ ] Decide what properties to officially support on the User object. At the time of writing, we support id, email, username and all other data is provider-specific and is accessible via the user's metadata array.
• [ ] Explore adding integrations/bridges (likely in separate repositories) for common frameworks such as Laravel/Symfony.

This PR started very small and only encompassed a bit of code abstraction and the creation of utility classes. The longer it sat waiting, the more refactoring I did. Now it has addressed #28 and #20 of the 2.0 milestone.

cc @bencorlett

These changes support the following public usage of the package:

// Create a server instance.
$server = new \League\OAuth1\Client\Server\GenericServer([
    'identifier'              => 'your-identifier',
    'secret'                  => 'your-secret',
    'callbackUri'             => 'http://your-callback-uri/',
    // These are only required for use with GenericServer
    'responseType'            => 'json', // Optional, defaults to 'json'
    'temporaryCredentialsUri' => 'http://your.service/temporary-credentials',
    'authorizationUri'        => 'http://your.service/authorize',
    'tokenCredentialsUri'     => 'http://your.service/token-credentials',
    'resourceOwnerDetailsUri' => 'http://your.service/me',
]);

// Obtain Temporary Credentials and User Authorization
if (!isset($_GET['oauth_token'], $_GET['oauth_verifier'])) {

    // First part of OAuth 1.0 authentication is to
    // obtain Temporary Credentials.
    $temporaryCredentials = $server->getTemporaryCredentials();

    // Store credentials in the session, we'll need them later
    $_SESSION['temporary_credentials'] = serialize($temporaryCredentials);
    session_write_close();

    // Second part of OAuth 1.0 authentication is to obtain User Authorization
    // by redirecting the resource owner to the login screen on the server.
    // Create an authorization url.
    $authorizationUrl = $server->getAuthorizationUrl($temporaryCredentials);

    // Redirect the user to the authorization URL. The user will be redirected
    // to the familiar login screen on the server, where they will login to
    // their account and authorize your app to access their data.
    header('Location: ' . $authorizationUrl);
    exit;

// Obtain Token Credentials
} else {

    try {

        // Retrieve the temporary credentials we saved before.
        $temporaryCredentials = unserialize($_SESSION['temporary_credentials']);

        // We will now obtain Token Credentials from the server.
        $tokenCredentials = $server->getTokenCredentials(
            $temporaryCredentials,
            $_GET['oauth_token'],
            $_GET['oauth_verifier']
        );

        // We have token credentials, which we may use in authenticated
        // requests against the service provider's API.
        echo $tokenCredentials->getIdentifier() . "\n";
        echo $tokenCredentials->getSecret() . "\n";

        // Using the access token, we may look up details about the
        // resource owner.
        $resourceOwner = $server->getResourceOwner($tokenCredentials);

        var_export($resourceOwner->toArray());

        // The server provides a way to get an authenticated API request for
        // the service, using the access token; it returns an object conforming
        // to Psr\Http\Message\RequestInterface.
        $request = $server->getAuthenticatedRequest(
            'GET',
            'http://your.service/endpoint',
            $tokenCredentials
        );

    } catch (\League\OAuth1\Client\Exceptions\Exception $e) {

        // Failed to get the token credentials or user details.
        exit($e->getMessage());

    }

}

When sending multidimensional array data through the client, you will get this error:

rawurlencode() expects parameter 1 to be string, array given

Is this a bug, or is this spec related?

@bencorlett Now that the develop branch is fresh with some of the new architecture I wanted to bring up the topic of moving the provider implementations to independent repositories. I noticed that there are some empty repos within thephpleague organization. Were those created with this purpose in mind?

• [x] oauth1-twitter maintained by @bencorlett
• [x] oauth1-trello maintained by @stevenmaguire
• [x] oauth1-bitbucket maintained by @stevenmaguire
• [ ] oauth1-xing
• [ ] oauth1-uservoice
• [ ] oauth1-tumblr
• [ ] oauth1-magento

I am happy to assume responsibility for a few of them to get the ball rolling. I'd prefer to take trello, tumblr, twitter, and bitbucket, as I have experience with those APIs.

What are your thoughts?

I'm working with an API (goodreads) that doesn't appear to be honouring it.

The check can be found here: https://github.com/thephpleague/oauth1-client/blob/4d4edd9b6014f882e319231a9b3351e3a1dfdc81/src/Client/Server/Server.php#L432

(Also worth noting is that the exception message being shown here could be a bit more descriptive.)

I am currently working on a OAuth 1 Server to be used in conjunction with this library. The OAuth provider allows for custom meta data to be passed to the authorization url with query string parameters.

The current behavior of this class is such that it blindly concatenates the urlAuthorization() and http_build_query($parameters) with a ? character separator.

I am proposing a change that adds a buildUrl method to the Server class. This method will now be used in the getAuthorizationUrl() method to return the complete authorization url.

With this change in place new Server implementations can declare urls that include query string parameters that will not break when the base Server class appends the oauth_token.

    /**
     * {@inheritDoc}
     */
    public function urlAuthorization()
    {
        return 'http://www.example.com/authorize?foo=bar';
    }
    //http://www.example.com/authorize?foo=bar&oauth_token=abcdefg

    /**
     * {@inheritDoc}
     */
    public function urlAuthorization()
    {
        return 'http://www.example.com/authorize';
    }
    //http://www.example.com/authorize?oauth_token=abcdefg

I've encountered an issue whereby if you create a service that extends League\OAuth1\Client\Server\Server and use $this->getHeaders(...) with a query string that has array notation (i.e. var[]=whatever) then the URL cannot be properly signed.

Here's an example:

$this->getHeaders($this->tokenCredentials, 'GET', 'https://myservice.com/hello?a=1&b=2&c[]=3&c[]=4&d[a]=5&d[b]=6');

This generates a warning: Warning: rawurlencode() expects parameter 1 to be string, array given in /my/proj/vendor/league/oauth1-client/src/Client/Signature/HmacSha1Signature.php on line 66

Which means that the service is sending an invalid signature.

When I dug deeper, it looks like the method League\OAuth1\Client\Signature\HmacSha1Signature::baseString does not properly operate on such nested arrays. Specifically this line: $data[rawurlencode($key)] = rawurlencode($value);. The method rawurlencode doesn't know how to act on an array.

Is this a bug or did I miss another way to sign a URL here?

Client version: 1.6.1

php -a
Interactive shell

php > parse_str('a=1&b=2&c[]=3&c[]=4&d[a]=5&d[b]=6', $query);
php > var_dump($query);
array(4) {
  ["a"]=>
  string(1) "1"
  ["b"]=>
  string(1) "2"
  ["c"]=>
  array(2) {
    [0]=>
    string(1) "3"
    [1]=>
    string(1) "4"
  }
  ["d"]=>
  array(2) {
    ["a"]=>
    string(1) "5"
    ["b"]=>
    string(1) "6"
  }
}
php > foreach ($query as $key => $val) { var_dump(rawurlencode($key), rawurlencode($val)); }
string(1) "a"
string(1) "1"
string(1) "b"
string(1) "2"

Warning: rawurlencode() expects parameter 1 to be string, array given in php shell code on line 1
string(1) "c"
NULL

Warning: rawurlencode() expects parameter 1 to be string, array given in php shell code on line 1
string(1) "d"
NULL
php > 

Problem

When duplicate params are passed (like ['test' => [ '123', '456' ]]), the signature should not add numeric indices to the generated base string.

The default behavior of EncodesUrl::baseString() is to parse the URL query string using parse_str. This works well for most cases, but in the case where clients repeat param names with different values (which is valid and accounted for in RFC 5849 Section 3.4.1.3.2 item 2) it does not work properly.

// Loses all but last value when duplicate params are included, signature generation will fail
parse_str('test=1234&test=5678', $params); // [ 'test' => '5678' ]

// Strips index from param name, indices need to be re-added during signature generation.
// One version of the other will fail. Currently, the first form can not be properly signed.
parse_str('test[]=1234&test[]=5678', $params); // [ 'test' => [ '1234', '5678' ] ]
parse_str('test[0]=1234&test[1]=5678', $params); // [ 'test' => [ '1234', '5678' ] ]

The Guzzle PSR-7 package provides Query::parse() that can handle query strings containing duplicate params. Calling code can strip the query string from the passed URL and the baseString() method can receive these as additional parameters:

// no information lost using Guzzle PSR-7
$params = Query::parse('test=1234&test=5678'); // [ 'test' => [ '1234', '5678' ] ]
$params = Query::parse('test[]=1234&test[]=5678'); // [ 'test[]' => [ '1234', '5678' ] ]
$params = Query::parse('test[0]=1234&test[1]=5678'); // [ 'test[0]' => '1234', 'test[1]' => '5678' ]

$oauthParams = ... ;
$queryParams = Query::parse($uri->getQuery(), PHP_QUERY_RFC3986);
$signature->sign((string) $uri->withQuery(''), array_merge($oauthParams, $queryParams), 'GET');

This should work, but the base string generation adds additional index numbers to the param name, causing signature generation to fail:

// correct
&test=1234&test=5678

// incorrect
&test[0]=1234&test[1]=5678

Solution

This PR changes the following:

1. When additional params are passed, sequential arrays do not get bracket suffixes added to param names. This allows the existing parse_str to work as before, but also allows using another library (like Guzzle) to parse query params and pass them in to baseString().
2. Params are sorted before being imploded. Sorting is done after the key-value pair strings are generated so it will sort first by param name and then by param value as per the RFC.

A new protected method paramsFromData() is added. The existing protected method queryStringFromData() is maintained, although it is now unused.

Background

Why does this matter? Multi-value parameters are an edge case, and for folks who can control all sides of the request signing, they can work within the confines of parse_str or modify requests to work. Folks attempting to integrate with producers/consumers using spec-compliant implementations written in other languages can't make these changes, and need this implementation to work per the RFC.

https://github.com/thephpleague/oauth1-client/commit/0a423aa9a3c7d1c7a8f3befd38acfff2ad972803#diff-23c1737a2e9df0d80059154c9a7878c3d6e59fd5bb93ad1966c2f01293a5398cR19

SignatureInterface is located in another directory and it should be imported like:

use League\OAuth1\Client\Signature\SignatureInterface;

Calling the class with parameter name don't seems to apply it to Trello.

$Trello = new Trello([
            'identifier' => c('TRELLO_KEY'),
            'secret' => c('TRELLO_SECRET'),
            'callback_uri' => Http::url(),
            'name' => c('APP_NAME'),
            'expiration' => 'never',
            'scope' => 'read,write'
        ]);

The value of APP_NAME get passed in the URL, but the result on the Trello auth-page is "An unknown application" instead of the expected value.

I really want to pass the configuration to Guzzle HTTP Client for setting timeout, and I have a proposal for that.

Add $clientOptions to the constructor of /src/Client/Server/Server.php

abstract class Server
{
    /**
     * @var array
     */
    protected $clientOptions;

    /**
     * Create a new server instance.
     *
     * @param ClientCredentialsInterface|array $clientCredentials
     * @param SignatureInterface               $signature
     * @param array  $clientOptions
     */
    public function __construct($clientCredentials, SignatureInterface $signature = null, $clientOptions)