Skip to content
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

v4 API: OAuth #74

Merged
merged 118 commits into from
Apr 17, 2024
Merged

v4 API: OAuth #74

merged 118 commits into from
Apr 17, 2024

Conversation

n7studios
Copy link
Contributor

@n7studios n7studios commented Mar 18, 2024

Summary

Implements the v4 API's OAuth implementation, removing API Key and Secret authentication.

Tidies up the make_request method, as 4xx and 5xx errors would always throw a ClientException or ServerException.

Tidies up the logging by removing repetitive log entries for helper methods get, post, put, delete.

Further PR's to follow to add, update and remove methods to provide full compatibility with the v4 API.

Testing

Tests outside of the scope of this PR are marked as incomplete using $this->markTestIncomplete(). As further PR's add compatibility to each section of the v4 API, these tests will be updated and the flag removed.

Added:

  • testGetOAuthURL: Test that the new get_oauth_url method returns the correct URl to begin the OAuth process.
  • testGetAccessToken: Test that the new get_access_token method returns the expected data.
  • testGetAccessTokenWithInvalidAuthCode: Test that the new get_access_token returns a ClientException when an invalid authorization code is specified.
  • testRefreshToken: Test that the new refresh_token method returns the expected data.
  • testRefreshTokenWithInvalidToken: Test that the new refresh_token returns a ServerException when an invalid refresh token is specified.

Updated:

  • testInvalidAPICredentials: Test that a ClientException is thrown when an invalid Client ID, Secret and Access Token is specified.
  • testGetAccount: Updated assertions to match the new shape of the account endpoint data

Removed:

  • testDebugAPIKeyAndSecretAreMasked: Credentials (such as Client ID, Secret, Access Token) are not logged. The Access Token is included in the header of any authenticated requests, and therefore again is not logged. Masking of the redundant API Key and Secret are no longer required.

Checklist

@n7studios n7studios added this to the 2.0 milestone Mar 18, 2024
@n7studios n7studios self-assigned this Mar 18, 2024
@n7studios n7studios requested review from a team, noelherrick and corydhmiller and removed request for a team March 20, 2024 12:43
@n7studios n7studios marked this pull request as ready for review March 20, 2024 12:43
Copy link

@noelherrick noelherrick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this all makes sense, but I am adding the primary developer on the API project to see if I'm missing anything.

@@ -1316,9 +1315,6 @@ public function delete_custom_field(int $id)
*/
public function list_purchases(array $options)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we have any parameters on this API call, so I don't know if we still want to keep this options parameter.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is presently unchanged, as I didn't want to submit a large, unreadable PR with all changes for v4 compatibility. I'll make sure this is addressed when submitting the v4 PR for purchases.

README.md Outdated Show resolved Hide resolved
src/ConvertKit_API.php Outdated Show resolved Hide resolved
@noelherrick noelherrick requested a review from mercedesb March 20, 2024 15:28
@noelherrick
Copy link

@mercedesb I would love to get your eyes on this implementation of the V4 API

Copy link

@mercedesb mercedesb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I caught everything but there are some breaking changes from V3 to V4 that need to be addressed. We have breaking changes documentation. And I'll get the couple items I noticed missing added to it too.

src/ConvertKit_API.php Outdated Show resolved Hide resolved
src/ConvertKit_API.php Outdated Show resolved Hide resolved
@@ -424,8 +539,7 @@ public function create_tag(string $tag)
return $this->post(
'tags',
[
'api_key' => $this->api_key,
'tag' => ['name' => $tag],
'tag' => ['name' => $tag],

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The request shape has changed in v4. The root tag attribute is no longer supported.

'api_key' => $this->api_key,
'tag' => $apiTags,
]
['tag' => $apiTags]

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Creating multiple tags is now under the bulk namespace.

'api_secret' => $this->api_secret,
'email' => $email,
];
$options = ['email' => $email];

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The param has changed in v4 from email to email_address.

'api_secret' => $this->api_secret,
]
);
return $this->delete(sprintf('subscribers/%s/tags/%s', $subscriber_id, $tag_id));

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this path should actually be sprintf('tags/%s/subscribers/%s', $tag_id, $subscriber_id). Ref

'api_secret' => $this->api_secret,
'email' => $email,
]
['email' => $email]

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

V4 doesn't currently support unsubscribing by email address.

'api_secret' => $this->api_secret,
]
);
return $this->delete(sprintf('automations/hooks/%s', $rule_id));

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Webhooks routes have changed from automations/hooks to webhooks in v4

@n7studios
Copy link
Contributor Author

@mercedesb I would love to get your eyes on this implementation of the V4 API

Thanks for the review. Scope of this PR is to support v4 OAuth:

Further PR's to follow to add, update and remove methods to provide full compatibility with the v4 API.

Comments noted for said future PR's.

@n7studios
Copy link
Contributor Author

I'm not sure I caught everything but there are some breaking changes from V3 to V4 that need to be addressed. We have breaking changes documentation. And I'll get the couple items I noticed missing added to it too.

Thanks for the review @mercedesb. The scope of this PR is to support v4 OAuth, for ease of review:

Further PR's to follow to add, update and remove methods to provide full compatibility with the v4 API.

If you and @noelherrick prefer, happy to combine all work into a single PR, though. Let me know!

@noelherrick
Copy link

@n7studios this PR is pretty thick as is, so I understand your hesitancy, but Mercedes suggested about 5 one-liners, so I don't think it would bloat it too much. I would hate for those suggestions to get lost, but that being said, I'm fine with not addressing them here as long as we account for all of those.

What is your plan for merging? It looks like this is the main PR that all the other PRs will merge into.

@noelherrick
Copy link

@mercedesb What did you think of the OAuth part specifically? Any comments around that since that's the heart of this PR? Also, this will supplant any usage of the V3 API - will we freeze the V3 API upon the release of V4? Or should there be a plan around releasing updates for consumers still on V3?

@mercedesb
Copy link

The scope of this PR is to support v4 OAuth, for ease of review

Sorry @n7studios, I missed that bit and jumped the gun. I have no preferences on how you manage the work needed to support V4, feel free to break apart PRs however makes sense to you.

What did you think of the OAuth part specifically?

The OAuth bits LGTM

Also, this will supplant any usage of the V3 API - will we freeze the V3 API upon the release of V4? Or should there be a plan around releasing updates for consumers still on V3?

We are not planning to make any more updates to V3, unless we find major security issues. So there should probably be a plan for releasing updates to V3 as a "just in case" though the likelihood is slim.

We plan to eventually sunset V3. But I expect that to take months since we have so many people using it.

V4 will eventually support API Keys to make that process easier for creators who are not planning on creating apps and just want to use the API for their own personal uses.

@n7studios
Copy link
Contributor Author

@n7studios this PR is pretty thick as is, so I understand your hesitancy, but Mercedes suggested about 5 one-liners, so I don't think it would bloat it too much. I would hate for those suggestions to get lost, but that being said, I'm fine with not addressing them here as long as we account for all of those.

Let's address those in separate PR's (as some are likely to be more than one liners e.g. needing to support cursor based pagination),. I'll add a comment to each linking to the separate PR, so they're tracked.

What is your plan for merging? It looks like this is the main PR that all the other PRs will merge into.

Correct - other v4 PR's will merge in to this one, which will then form our final PHP SDK implementation into the main branch and subsequently published as version 2.0 of our SDK.

@n7studios
Copy link
Contributor Author

Sorry @n7studios, I missed that bit and jumped the gun. I have no preferences on how you manage the work needed to support V4, feel free to break apart PRs however makes sense to you.

Thanks for reviewing - happy to assign you to other PRs if you'd like to review, as appreciate your input here.

V4 will eventually support API Keys to make that process easier for creators who are not planning on creating apps and just want to use the API for their own personal uses.

Will API Key + Secret authentication work in the same way as it does in the v3 API? Appreciate this isn't supported right now, but want to make sure this SDK is designed to accommodate both methods (API, OAuth) in the future.

@mercedesb
Copy link

Will API Key + Secret authentication work in the same way as it does in the v3 API?

Not the exact same way, but close. We want to adhere to RFC6750. So we'll be using the Authorization header. And there won't be a secret.

I'm hoping to add support for creating multiple API keys (rather than just one) so that when we get to the point of supporting scopes (for OAuth too), then we can limit specific OAuth apps and API Keys on read/write permissions for specific resources so creators can have more fine-grained control.

We won't be migrating V3 keys b/c we don't want to break existing landing page embeds and some other functionality so all V4 keys will be new.

@corydhmiller corydhmiller removed their request for review March 21, 2024 14:19
n7studios added 28 commits April 2, 2024 17:18
This allows specific headers to be defined depending on the request i.e. an API request or fetching HTML.
v4 API: Forms and Landing Pages: Pagination and Total Count
@n7studios n7studios merged commit 503cfea into master Apr 17, 2024
4 checks passed
@n7studios n7studios deleted the v4-api-oauth branch June 26, 2024 03:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants