-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Next Version #111
Next Version #111
Conversation
c5bf2e3
to
4447f55
Compare
c08a56e
to
581c5fb
Compare
f1f7a96
to
7ca7918
Compare
@mfn not so much anymore! |
4c82661
to
e9ee7ed
Compare
c52005b
to
680b318
Compare
…ntation of the HMAC-SHA1 signature.
…o building signature base strings.
…ter implementation for development purposes. The Twitter provider will be likely separated into a standalone package and we’ll only ship with a spec compliant, OAuth 1 provider.
…en getting various URLs.
…nd feel of the rewrite to date.
…concerns and starts improving test coverage of implementation thus far.
…1 compliant servers and for the purposes of testing the functionality exposed by the base provider.
… the normalized parameters which meant it wasn’t providing the correct base string for signature generation.
…cenarios, and of course, 100% LOC coverage.
…her linting practices I like such as aligning equal signs.
680b318
to
73399b0
Compare
I'm not familiar with this implementation (so many changes 🙀) and I'm not sure if this it the proper forum to bring this up. guzzle/oauth-subscriber works by storing the token credentials on the class in the constructor. This means once instantiated, this "state" persists to all requests performed with it. I've a use-case where I want to pass these credentials on a per request basis (by allowing credentials being passed via Guzzles
This is useful when interacting with multiple identities but not requiring to have multiple HTTP clients for this. I searched for an opportunity to mention this somewhere in the hopes there are peers recognizing this as a valid use-case. Right now, to solve this, I've had to copy OAuth1 into a private source tree and adapt it accordingly. The discussion in #88 triggered me to write this here. |
I see.
Why don’t you want to create a separate client instance for each account you’re acting on behalf of?
Having said that, I can see your use-case being solved with this new version pretty much out of the box.
There’s a new $client->executeAuthenticatedRequest() method now. We take a PSR-7 request (guzzle satisfies this requirement) and also a PSR-18 HTTP client (guzzle also satisfies this).
I’ll put some more thought into it and come back with an example soon.
…Sent from my iPhone
On 3 Sep 2020, at 2:29 pm, Markus Podar ***@***.***> wrote:
Add a handy Guzzle middleware to sign authenticated OAuth 1 requests, or recommend the usage of the official OAuth subscriber.
I'm not familiar with this implementation (so many changes 🙀) and I'm not sure if this it the proper forum to bring this up.
guzzle/oauth-subscriber works by storing the token credentials on the class in the constructor. This means once instantiated, this "state" persists to all requests performed with it.
I've a use-case where I want to pass these credentials on a per request basis (by allowing credentials being passed via Guzzles $options). This frees the Guzzle client from being tied to a specific set of credentials and allows to be more conservative with resources and logic:
a single Guzzle client instance can be used for all instances, as it's not tied to a set of credentials
every call explicitly can pass a different set of credentials
This is useful when interacting with multiple identities but not requiring to have multiple HTTP clients for this.
I searched for an opportunity to mention this somewhere in the hopes there are peers recognizing this as a valid use-case. Right now, to solve this, I've had to copy OAuth1 into a private source tree and adapt it accordingly.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Persistent background worker job connecting to the same remote OAuth1 system on behalf of identities likely different for each job. To conserve memory and reduce GC, I try to make objects "stay" if possible, make them state-less so they can be shared like this. Thanks! |
…and suggests to install the OpenSSL extension if you plan to use this.
bb08f56
to
859ad7b
Compare
…in preparation to introduce the RSA-SHA1 signer.
…ndicate the correct return types due to a shared trait. This issue upsets both PHPStorm and PHPStan and the workaround solves this.
c9a5707
to
241b612
Compare
…7.4 when pulling in the lowest deps. Shoutout to @arcanedev-maroc for this!
Because we integrate with PSRs, we only had to decouple our test suite from Guzzle because only Guzzle 7 provides PSR-18 support and Guzzle 7 requires PHP 7.2+. We switched this implementation out for a popular Guzzle 6 adaptor, which we don’t even use in our tests as we mock PSR-18.
Hi @mfn, here's a snippet of how I would solve your problem. I've included all of the boilerplate as well as I'd like to know your thoughts on it overall: <?php
require_once __DIR__.'/vendor/autoload.php';
// Boilerplate to create a Twitter provider
$twitter = new League\OAuth1\Client\Provider\Twitter(
new League\OAuth1\Client\Credentials\ClientCredentials(
'app-id',
'app-secret',
'https://api.client.com/callback',
)
);
// Create an OAuth client, giving a provider, PSR-17 HTTP request factory and PSR-18 client.
//
// You can use:
// 1. `http-interop/http-factory-guzzle` for the PSR-17 HTTP request factory
// 2a. `guzzlehttp/guzzle` (v7 for PHP 7.2+) or
// 2b. `php-http/guzzle6-adapter` (for PHP 7.1)
//
// I'm currently testing the package in PHP 7.1, so I'm using 1 and 2b from above
$oauthClient = new League\OAuth1\Client\Client(
$twitter,
new Http\Factory\Guzzle\RequestFactory(),
new Http\Adapter\Guzzle6\Client()
);
// Now you need a PSR-7 request, I use `guzzlehttp\psr7` for this
$request = new GuzzleHttp\Psr7\Request('GET', 'https://api.example.com/me');
// Here's your token credentials / access tokens
$tokenCredentials = new League\OAuth1\Client\Credentials\Credentials('token-id', 'token-secret');
// Now, you could either set this with the client for continual use:
//
// $oauthClient->setTokenCredentials($tokenCredentials);
// $response = $oauthClient->executeAuthenticatedRequest($request);
//
// However you won't want to do this as this sets the token credentials for the client overall.
// You might want to send unique token credentials every time:
try {
$response = $oauthClient->executeAuthenticatedRequest($request, $tokenCredentials);
} catch (Psr\Http\Client\ClientExceptionInterface $e) {
//
} catch (Throwable $e) {
//
} |
@mfn out of curiosity - are you integrating with a known OAuth 1 provider? I'm looking through what still uses OAuth 1 and there isn't a lot! |
@bencorlett The code in general looks fine to me and decouples the token credentials, seems exactly what I was talking about.
Yes, Twitter ;) Currently using guzzle/oauth-subscriber absorbed in the code base and adapted to serve the use-case. Once a (dev) release is available, I can try integrating it and see how it works out. At first the code looks boilerplate-y though, but I might judge this wrong. I'm just used to directly use Guzzle 6 and not having to deal with the abstractions too much. Thanks! |
Yeah the cost of decoupling from dependency implementations is you must supply said implementations.
Having said that, we’ll likely ship with a Guzzle 6/7 factory for convenience.
…Sent from my iPhone
On 4 Sep 2020, at 4:18 pm, Markus Podar ***@***.***> wrote:
@bencorlett The code in general looks fine to me and decouples the token credentials, seems exactly what I was talking about.
are you integrating with a known OAuth 1 provider?
Yes, Twitter ;)
Currently using guzzle/oauth-subscriber absorbed in the code base and adapted to serve the use-case.
Once a (dev) release is available, I can try integrating it and see how it works out. At first the code looks boilerplate-y though, but I might judge this wrong. I'm just used to directly use Guzzle 6 and not having to deal with the abstractions too much.
Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Will open additional PRs for further work. Develop will point to the next version from now on. |
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:
PSR-7
,PSR-17
andPSR-18
, providers have a lot more flexibility to setup unique requests if they need to instead of overriding a lot of functionality.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 theGeneric Provider
out of the box.To do:
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…User
object. At the time of writing, we supportid
,email
,username
and all other data is provider-specific and is accessible via the user's metadata array.