🇺🇸United States @fathershawn

There are a variety of ways that to customize aspects of the flow. If you don't want to post publicly what it is that you need to change, perhaps you could DM me in Drupal Slack.

Sounds good. Please do report back on what you find.

Do you know how to use Devel module functions → or even better Xdebug to inspect values as the code executes?

The request/response exchange you will want to examine is at vendor/league/oauth2-client/src/Provider/AbstractProvider.php:645-646

I don't have a USPS account and I can't directly debug this. I don't have any other reports of client credentials not working. If it still doesn't work then either the URLs have to be wrong or you may have a typo in the client id or client secret. I can't think of anything else

I just do not see where it is put into or called into the body as a parameter.

You don't see it here as it is in the upstream library. Here's a GitHub link since I can't link to your code to the default options for POST, which is the default method: https://github.com/thephpleague/oauth2-client/blob/8cc8488e627ab17b71238ef4c09235e95f4d5068/src/OptionProvider/PostAuthOptionProvider.php#L30

The upstream library expects Guzzle. You may be able to use custom code to implement something with curl but that's not the standard practice in PHP now. Guzzle is pretty ubiquitous. I've removed the scopes since that's optional and corrected the test plugin id.

That is what I last had in #24 calling by variable

Your metadata is not correct in #24.

believe it is continuing to send data in a header

Can you point to where that is happening in my code or the upstream library? I'm not aware of such logic and will need to fix it if true.

I have attached a module with example plugins for your use case. Please let me know if they work, and this back and forth is not producing a conclusion.

Looks like a Guzzle issue, but why is it trying to call "OwnerCredentials" ???

OwnerCredentials is a value object that contains the client id and secret. It is used to pass those values so that they don't get captured by logs unintentionally revealed.

You are actually successfully communicating with USPS: https://developer.usps.com/oauth#tag/Resources/operation/post-token invalid_request is from them and the exception is thrown because an HTTP code 200 is not received.

This module should log the exception in a way that includes the return code and that will give you more of a clue.

But you may not need this last round of customizations. The documentation page I found and linked above shows application/json as a option not a requirement! In the right sidebar one can switch between that and the standard application/x-www-form-urlencoded so they do accept standard Oauth2.

Scope is listed as optional in the standard, but maybe not for USPS?

Note that they include scope in their example values:

urlencoded:

grant_type=client_credentials &client_id=123456789 &client_secret=A1B2C3D4E5 &scope=ResourceA+ResourceB+ResourceC

json:

{
  "grant_type": "client_credentials",
  "client_id": "123456789",
  "client_secret": "A1B2c3d4E5",
  "scope": "ResourceA ResourceB ResourceC"
}

So try adding a scope value or values to your plugin annotation.

Do you have database logging enabled? If not do you have access to PHP error logs? Can you post any errors shown in your logs?

The \League\OAuth2\Client\OptionProvider\PostAuthOptionProvider enforces the content type and encoding in the Oauth2 standard. We need to override that to set the json option, so you will want your own options provider class. Place this class in your module at src/OAuth2/Client/OptionProvider/UspsClientCredentialsOptionProvider.php, and be sure to set the namespace to the right value for your module.

declare(strict_types=1);

namespace Drupal\your_module\OAuth2\Client\OptionProvider;

use Drupal\oauth2_client\OAuth2\Client\OptionProvider\ClientCredentialsOptionProvider;
use Drupal\oauth2_client\Plugin\Oauth2Client\Oauth2ClientPluginInterface;

/**
 * An option provider which alters the token request content type.
 */
class UspsClientCredentialsOptionProvider extends ClientCredentialsOptionProvider {


  /**
   * A string of scopes imploded from the Oauth2ClientPlugin.
   */
  private string $scopeOption;

  /**
   * {@inheritdoc}
   */
  public function __construct(Oauth2ClientPluginInterface $clientPlugin) {
    $scopes = $clientPlugin->getScopes();
    if (!empty($scopes)) {
      $this->scopeOption = implode($clientPlugin->getScopeSeparator(), $scopes);
    }
  }

  /**
   * {@inheritdoc}
   */
  public function getAccessTokenOptions($method, array $params): array {
    if (!empty($this->scopeOption)) {
      $params['scope'] = $this->scopeOption;
    }
    return ['json' => $params];
  }

}

Next, add an override in your plugin class. First add the proper use statement for your new options provider:

  use Drupal\your_module\OAuth2\Client\OptionProvider\UspsClientCredentialsOptionProvider;

Then override the getProvider method.

  /**
   * {@inheritdoc}
   */
  public function getProvider(): AbstractProvider {
    $provider =parent::getProvider();
    $provider->setOptionProvider(new UspsClientCredentialsOptionProvider($this));
    return $provider;
  }

I think I found the disconnect! The Oauth2 standard for client credentials states:

The client makes a request to the token endpoint by adding the
following parameters using the "application/x-www-form-urlencoded"
format per Appendix B with a character encoding of UTF-8 in the HTTP
request entity-body

However, your reference to Postman prompted me to go look at the USPS examples in GitHub again. Both the Postman file and the curl example use a non-standard json content type:

curl -X 'POST' 'https://apis.usps.com/oauth2/v3/token' \
     --header 'Content-Type: application/json' \
     --data '{
		"client_id": "{{CLIENT_ID}}",
		"client_secret": "{{CLIENT_SECRET}}",
		"grant_type": "client_credentials"
		}'

This has to be the source of your failure and I'll post back code in a bit you can add to your plugin to override the standard setting.

So does the client credentials flow send only a POST by default??? If so then the modification is only to send the data params in the body and not the header like the last thing I asked about the $options section I posted of the example using your previous code solution.

All of the token requests are POST by default.

All of the POST requests send the data in the body, content 'application/x-www-form-urlencoded' by default. That is to say the request sends data as if it were submitting an HTML form. This is default Oauth behavior.

I don't know why your plugin implementation is not working, but neither request method nor non-standard data transmission are not the reasons. You've talked about changing the corresponding configuration entity form. Have you done so? If so please revert your version of this module to the released state before we continue.

Please post the current state of your plugin class.

Tests passed

Thanks for the report. Found the issue and creating a fix

fathershawn → made their first commit to this issue’s fork.

Good changes to the summary @catch!

I think the simplest way is to use this module's original default method on the /donate route as that establishes a dedicate checkout flow to build and process the donation transaction. We provide a field for monthly here, but you would need to investigate how to use that with the Commerce integration for Stripe:

• https://www.centarro.io/drupal-commerce/integrations/stripe
• https://www.drupal.org/project/commerce_stripe →

You might find that you need to extend our dedicated checkout flow plugin to do more work in the submit method. If you let me know what you find I'm happy to continue to advise/help. This issue hints at the configuration for repeating payments: 📌 Make sure recurring payments are working properly Fixed

It could. I ported this code to a contributed module from an unreleased client project. In that project the recurring payment was a feature of their processor. One route would be to complete integration with commerce_recurring if that supports what you need. Another is to customize the submission logic in the checkout process.

If you let me know what direction you would like to go and which checkout route you would be using I can give more advice.

I'm happy to keep chatting. This felt like a conclusion to me:

OK, thanks I will see what I can do in the client form with a for example

if ($grantType == 'client_credentials') {
$form['oauth2_client']['data in body'] = [
'#type' => 'checkbox',
'#title' => $this->t('Enabled'),
'#default_value' => $this->entity->point to the code needed(),
];

As needed et cetera and it will be a stretch to my skills to cobble together but there is other code helpful on the internet on the issue as it is a common problem one

However my support for you is challenging each post from you has multiple topics/threads and often I can't see how it connects to what I last said. I'm gathering that you are fully focused on getting connected to USPS and aren't willing to take the interim step of getting Oauth working in your site in general to known test service, so let's stay with that, and I'll try to explain what you are seeing in their examples and how it relates to what I have written.

I wrote

The initial auth code request is a GET to a url on the remote service where the user logs in, authorizes the connection. This generates a code which is sent in a query parameter to the original site (Drupal) which then makes a POST to a token url with that code to get the token.

And your reply is

It sounds like you are saying it sends a GET request first, which the server you say sends back a response and then this client software sends a POST. Well the first GET sent will cause a FAIL - period - there will be no further communication as USPS has set it up

If you look at the Example OAuth Client Credentials Token request on the USPS example page onb Github, there is one POST to the /token URL ad that is all - with the data sent in the body. That is what works, and all that works - so how is this module stopped from sending the intial GET request in favor of the POST wit the data in the body

I am describing the process for the authorization code flow and you are responding about the client credentials flow. This module will not send the client credentials token request, or any token request in a GET since I am not overriding the default in the upstream library.

It seems like you keep switching between grant flows. Let's pick one, stick with it, and get it working for you.

The token request is normally sent in the body here.

Look at \Drupal\oauth2_client\Plugin\Oauth2Client\Oauth2ClientPluginBase::getProvider.

This method instantiates \League\OAuth2\Client\Provider\GenericProvider

Look at \League\OAuth2\Client\Provider\GenericProvider::getAccessTokenMethod which if there is no override value created above calls \League\OAuth2\Client\Provider\AbstractProvider::getAccessTokenMethod which returns POST.

The initial auth code request is a GET to a url on the remote service where the user logs in, authorizes the connection. This generates a code which is sent in a query parameter to the original site (Drupal) which then makes a POST to a token url with that code to get the token.

This module would allow you to completely customize all the available options in GenericProvider or AbstractProvider by overriding ::getProvider in your plugin and changing how the provider is instantiated.

Yes, you can install the Devel Kint module and use the dpr() function to print any variable to data to the browser.
See https://www.drupal.org/docs/extending-drupal/contributed-modules/contributed-module-documentation/devel/introduction →

I still recommend you simplify your problem and get an auth code flow working against a reliable testing service and then pivot to USPS.

The plan was to use the Oauth2Client module for token management purposes for access only, Otherwise yes I would need far too many plugins. My other file is set up for CURL calls that would handle the API calls. I would only need the initial client credentials for authcode file, and the access file, and a refresh file I have not built yet

That's a good plan, and this module is not only for getting the initial token but for managing the refresh token. It allows a developer to just use Oauth and not mess with the details. With this module you don't have to manage the details of an auth code flow, neither the code nor the state parameter, nor storing the refresh token, nor using the refresh token to get a fresh token. All of that is what this module is for. It's not clear from this thread why the USPS service isn't working for you. I don't have access to it so can't debug it.

This module is built to integrate Drupal with the excellent Oauth2 Client PHP library, and both it and the upstream library conform to the Oauth2 standards.

It seems like you are facing two challenges. One is implementing Oauth in your Drupal code and the other is connecting with USPS. My only remaining suggestion is to simplify the problem and just work at implementing Oauth in your code. The folks at Okta provide an Oauth playground. They don't offer client credentials but they do offer Auth code workflow. You can register an account and get oauth working in your code. Then you can repoint your working code at USPS, and if it doesn't work then something is off and you should reach out to them.

fathershawn → created an issue.

Are you saying to add the code from #11 to the plugin or elsewhere or is it already existing code elsewhere in the module ???

It's in the trait that you have included in the plugin already.

As to the "scope" suggestion, it is my understanding until an initial token is obtained there is no API access and then the scope access request issues are then needed. The initial token is critical to moving forward at all. You cannot jump into scope issues at all.

This is not in keeping with the spec: https://datatracker.ietf.org/doc/html/rfc6749#section-3.3 explained in more plain language at https://oauth.net/2/scope/. The scope is encoded in your token.

You've added an unsupported property into your plugin definition, which is probably benign but I'm not sure:

 * state = "nonce=abscdefg#",

This module takes care of the state management.

You also have removed the two essential urls from the plugin definition for the authorization code flow. This module includes a default redirect url but you need these two as the module has no idea how to communicate with USPS.

 *   authorization_uri = "https://apis.usps.com//oauth2/v3/authorize",
 *   token_uri = "https://apis.usps.com/oauth2/v3/token",

Changing the file and rebuilding the cache does not show up changes in the config page for me - only a fresh file and flushing caches to rediscover works.

That's my mistake, forgetting a recent architecture improvement. I'll add an improvement ticket that makes it easier to clear. What's going on there is the UI is showing a set of configuration entities, which match 1:1 with the plugins, and are created when plugins are discovered. But plugin definitions are 100% cleared when the cache is rebuilt and any new plugin ids get paired with a config entity in \Drupal\oauth2_client\Plugin\Discovery\Oauth2ClientDiscoveryDecorator::getDefinitions

if I cannot get and store a token for access , that is moot.

These plugins will handle requesting and storing your token. Since you have success_message set to true in your definition, the code I posted at the end of #11 will tell you that a token was stored.

Plugin definitions are cached in Drupal, but a cache rebuild will refresh the definition. To verify that this is working, change the name property from "Code grant" to something else, maybe "USPS", and rebuild your cache. You should see the name change on the configuration page.

I think the source of your failure is missing scope in your client definition. Looking at the USPS API documentation, scope is required and it differs between APIs. For example, the address api (https://developers.usps.com/addressesv3#tag/Resources) within the Authorize details has Required scopes: addresses It looks to me like you will want a Drupal plugin for each of these API endpoints in which you set the scope property in your plugin to the required value. You could try a list of scopes, the most common separator is comma but the Oauth2 spec is space delimited and that API is already being obstinate so I'd at least start with just one scope and use it for one endpoint.

So does editing the file after discovery do NOTHING?

I can see that you are frustrated, and I am trying to help, so please try to be patient and don't shout. There are a lot of questions in your last comment. It will be much easier in this format if we go step by step, but I'll try to answer all your questions and then go back to the step 1 I requested in #9.

The documentation shows the " * " comment frame removed for the "Instagram" access example - while it ony works leaving it in place. I renamed the files to single word titles as classes

I see the difference now between attribute and annotation. The examples are attribute, and the Instagram example is annotation.

The code examples in README.md are meant to illustrate both the new Attribute based discovery/metadata and the retiring Annotation based approach. A made up example for Instagram is given in both syntaxes. Both are supported for now and Attribute is the long term approach. Attributes use a PHP8 language feature and Annotations use comments.

The examples sub-module still uses the older Annotation syntax.

You still did not say where does and how does the

$access_token = Drupal::service('oauth2_client.service')->getAccessToken($client_id);
$token = $access_token->getToken();

go in the code??

The purpose of this module is to make it easy for you to get the token value in your own code, without needing to build an oauth client. When you make a request to an Oauth2 protected api, such as the USPS api that you referer to, you need this token in your request header to authorize the request. Your api give a curl based example;

curl	-X 'GET' 'https://apis.usps.com/addresses/v3/address?streetAddress=3120%20M%20St&secondaryAddress=NW&city=Washington&state=DC&ZIPCode=20027&ZIPPlus4=3704' \
	--header 'accept: application/json' \
	--header 'authorization: Bearer $TOKEN' \

PHP commonly uses Guzzle for such requests and Drupal provides a factory for Guzzle clients, \Drupal\Core\Http\ClientFactory which has a means for setting these headers.

I have edited the client form to include the CRID and MID.

I don't recommend this as I have not had time to implement plugin specific forms. I don't see anywhere in the api documents that you linked that these values are needed to get a token, which is our goal here. There's a way to include them in a custom Key file but let's set that aside for now.

Now your custom plugin looks like it's account for all 4 of my steps. This looks right to me, but you should remove the blank line between the annotation and class declaration.

declare(strict_types=1);

namespace Drupal\xxxxxxxxxxxxx\Plugin\Oauth2Client;

use Drupal\oauth2_client\Plugin\Oauth2Client\Oauth2ClientPluginBase;
use Drupal\oauth2_client\Plugin\Oauth2Client\StateTokenStorage;

/**
* Auth code
*
* @Oauth2Client(
* id = "code",
* name = @Translation("Code grant"),
* grant_type = "client_credentials",
* authorization_uri = "https://apis.usps.com/oauth2/v3/token",
* token_uri = "https://apis.usps.com/oauth2/v3/token",
* success_message = TRUE
* )
*/
class Code extends Oauth2ClientPluginBase {
  use StateTokenStorage;
}

I don't recommend storing your secrets in config, but for testing it's okay. If you remove the changes you made to my form, enter your client id and secret and test your plugin. If it works, you will get a message

/**
   * Stores access tokens obtained by the client.
   *
   * @param \League\OAuth2\Client\Token\AccessTokenInterface $accessToken
   *   The token to store.
   */
  public function storeAccessToken(AccessTokenInterface $accessToken): void {
    $this->state->set('oauth2_client_access_token-' . $this->getId(), $accessToken);
    if ($this->displaySuccessMessage()) {
      $this->messenger->addStatus(
        $this->t('OAuth token stored.')
      );
    }
  }

I recommend that you start over. The examples are intended to document how you would create a plugin class for your use case. None of them will work as is for your use case as your grant type is not used in any of the examples.

I recommend that you remove all of your copies and start fresh. If you need step by step guidance in building a plugin class, we can do that here, just post your code after each step below. In general you need to:

1. Create your own plugin class that extends \Drupal\oauth2_client\Plugin\Oauth2Client\Oauth2ClientPluginBase
2. Decide on the appropriate token storage for your use case and use the provided trait for that storage
3. Decide on Attribute → or Annotation → for your plugin definition method.
4. Add the proper data using Attribute/Annotation to setup the plugin for your use case. Possible values are in \Drupal\oauth2_client\Annotation\Oauth2Client or \Drupal\oauth2_client\Attribute\Oauth2Client.

Super news!

If you don't see your plugin listed at /admin/config/system/oauth2-client then your plugin is not being discovered.

You should see it listed like this:

And when you edit it you will see a credential section. With Key module installed you will see a selector for provider and when Key is selected a select to choose your key.

Double check the placement of your plugin class in your custom module. It should be in directory src/Plugin/Oauth2Client

Are you using Attribute or Annotation for metadata?

You will see the form when you configure the client. I know the documentation is minimal but have you followed https://www.drupal.org/docs/contributed-modules/oauth2-client/oauth2-cli... → ?

Can you be more specific about what credential data you need beyond client id and secret?

There has been no response from the project owner for 28 days

Do you have steps to reproduce?

fathershawn → made their first commit to this issue’s fork.

All good ideas. When I have time to refactor I'll review this for features in the next version.

Biweekly progress check-in meetings are now happening the htmx channel desecribed in #85

@greggles Absolutely happy to continue the basic maintenance.

@cmlara is also correct and change logs on maintainer permissions would definitely have made this issue trivial to fix and false claims easy to verify.

https://www.drupal.org/project/commerce_purchase_order/releases/2.1.0 →

Thank you! very kind :)

That alter hook was never present on a stable release. The grant workflows are specified in the Oauth2 standard, which is why I removed the hook as I was converting this system to a plugin. If you aren't comfortable putting what and why you need to alter a grant type, please DM me in Drupal Slack. Otherwise can you describe what it is that needs to be different and if that difference is supported by the Oauth2 standard but not by this module?

I'll have a look at the history of that class and get back to you.

Thanks for considering my feedback.

Thanks - I did read that issue. The contextual crop approach is super useful - really like this idea!

I understand that swapping a modified class is more work but there are good reasons to do it:
- Users don't have to understand how to alter their composer.json if they aren't using patches already.
- I am using patches so I'm not sure why it didn't patch, but explicitly decorating a service or altering a route is more reliable.
- If a user uninstalls your module, the modifications are removed. With the patch approach when I uninstall the the module via Drupal the patch remains. Even if I composer remove, the patch remains unless I'm already patching that module or core myself for another issue.

Thanks for confirming - merging so I can tag

Thanks for the prompt! I was working on 📌 Add a sub-module that can be used if DS is present. Active locally without creating an issue here in the queue, which will require v13 but a release hasn't come out yet. Give a quick look at the MR - tested a generator command locally and all seems well.

fathershawn → made their first commit to this issue’s fork.

This will be a new feature for v1.1

The upstream changed was merged on Dec. 10, 2024. Waiting on a new release of Drush.

fathershawn → created an issue.

I didn't check if that patch had applied, but I did search my entire codebase for the existence of those methods and I did manually inspect the parent class. So I think we can be confident that it did not apply.

Further, patching core in a contrib module is not generally a good plan. A better approach would be to include the altered ImageStyleDownloadController here in your module and then also alter the image.style_public and image.style_private routes here in your module to use your substitute controller.

fathershawn → created an issue.

Thank you as always Alberto :)

Thank you - what ever is required by the policy. I've been maintaining this module since July 2017. If @guillaumev still wants ownership that's fine and I'm sure he will restore my permissions then.

Yes, I created the D8 version of this project and have maintained it by myself since July 2017. I created it for a client that I no longer have but maintain it for the community. The owner last posted a few weeks ago so we will hear from him I'm sure.

I'll create the release as soon as I have the correct privileges again.

A log is a good idea. In this case I'm sure I've edited the project node in the last 7 years. I know that I've created release nodes, and I'm the only user to commit to this project in that time. It was definitely thoughtless to lock myself out, and I can wait for the timer to expire or perhaps we will hear from the owner on my request to transfer.

I don't have personal urgency but a user has asked for the D11 release now that Commerce has a D11 release.

Contacted @guillaumev via his contact form.

fathershawn → created an issue.

fathershawn → created an issue.

Absolutely - thanks for the prompt! I hadn't checked in a few weeks.

Thank you very much, both of you :)

Thanks @nikunjkotecha for the endorsement! The message I sent was to Avinash because of the policy @avpaderno stated in his comments.

If the process is inflexible we can wait @avpaderno but I'd like to point out that I did attempt to follow the policy by contacting Avinash and by posting an issue that sat silently for more than the two weeks expected and that we are not truly proposing to "create a different project" as what exists is a placeholder: https://git.drupalcode.org/project/dynamic_yield.

I appreciate your care in maintaining drupal.org and in protecting drupal sites against supply chain poisoning!

Hi - That's precisely the approach - to customize the provider as you need in your implementation!

For storage you can you use similar methods to the token storage and use which ever method you chose for that to store this code.

I plan to switch to the new GitLab pages soon - thank you for this question as it will be a good case to document.

Thank you @avpaderno. I sent a similar message on Jan. 17 when I created this issue and attempted to follow the guidelines. Thank you for correcting our process. We will monitor for a response.

greggles → credited fathershawn → .

The `dynamic_yield` project consists of a one line README file created 4 years ago.

My employer is sponsoring the creation on a module to integrate the Dynamic Yield personalization service with Drupal which we intend to contribute.

I used the drupal.org contact form to contact the project owner over 2 weeks ago and have had no reply. It appears that this project is abandoned and I am requesting ownership so that we can use it for our contribution.

I am happy to accept ownership of oauth2_client

fathershawn → created an issue.

It was so encouraging to have all the discussion on this idea this week. The most helpful thing anyone can do to move forward is to review the approach in 📌 [POC] Implementing some components of the Ajax system using HTMX Active and suggest improvements or give a +1. It does not seem prudent to build out an implementation until we have consensus.