[PR #675] Fix parsing Withings new response format Fix OAuthSwift/OAuthSwift#663 #716

Open
opened 2026-03-03 17:29:48 +03:00 by kerem · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/OAuthSwift/OAuthSwift/pull/675
Author: @BJAdeGraaf
Created: 8/30/2021
Status: 🔄 Open

Base: masterHead: fix/withings-endpoint


📝 Commits (1)

📊 Changes

1 file changed (+5 additions, -1 deletions)

View changed files

📝 Sources/OAuthSwiftClient.swift (+5 -1)

📄 Description

As stated in #663, the new Withings endpoint:

  1. requires a parameter action, with value "requesttoken";
  2. requires parameter grant_type to equal "refresh_token" (not "authorization_code");
  3. and has the response structured differently: the keys of the response are now just body and status, with the former keys, including code, all in an object down below body.

Description code change:
This PR addresses nr.3, because nr.1 and 2 don't need code modifications (see below).
The provided solution extracts the response parameters if the response dictionary contains a key body. To my knowledge, only Withings uses this particular response format.

Requirement nr.1:
To mitigate requirement nr.1, the user can append the accessTokenUrl with ?action=requesttoken, i.e.:

oauthswift = OAuth2Swift(
    consumerKey:    "********",
    consumerSecret: "********",
    authorizeUrl:   "https://account.withings.com/oauth2_user/authorize2",
    accessTokenUrl: "https://wbsapi.withings.net/v2/oauth2?action=requesttoken",
    responseType:   "code"
)

This is more of a workaround, but it works. As such, no modifications are needed in the source code. An alternative would be to introduce a boolean, specifically to accommodate Withings. My preference is to omit such special cases as much as possible. But please give feedback if this workaround is not preferred.

Requirement nr.2:
Requirement nr.2 is already implemented, and doesn't need any changes: github.com/OAuthSwift/OAuthSwift@d85964b96d/Sources/OAuthSwiftClient.swift (L201)

I have tested it, and with these changes, I can successfully authorize with Withings and can also refresh the token.


🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/OAuthSwift/OAuthSwift/pull/675 **Author:** [@BJAdeGraaf](https://github.com/BJAdeGraaf) **Created:** 8/30/2021 **Status:** 🔄 Open **Base:** `master` ← **Head:** `fix/withings-endpoint` --- ### 📝 Commits (1) - [`75e32f4`](https://github.com/OAuthSwift/OAuthSwift/commit/75e32f4ddf5251ff7e8e3670b042c2471b0e0b22) Fix parsing Withings new response format Fix OAuthSwift/OAuthSwift#663 ### 📊 Changes **1 file changed** (+5 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `Sources/OAuthSwiftClient.swift` (+5 -1) </details> ### 📄 Description As stated in #663, the new Withings endpoint: 1. requires a parameter `action`, with value "requesttoken"; 2. requires parameter `grant_type` to equal "refresh_token" (not "authorization_code"); 3. and has the response structured differently: the keys of the response are now just `body` and `status`, with the former keys, including `code`, all in an object down below `body`. **Description code change:** This PR addresses nr.3, because nr.1 and 2 don't need code modifications (see below). The provided solution extracts the response parameters if the response dictionary contains a key `body`. To my knowledge, only Withings uses this particular response format. **Requirement nr.1:** To mitigate requirement nr.1, the user can append the `accessTokenUrl` with `?action=requesttoken`, i.e.: ```swift oauthswift = OAuth2Swift( consumerKey: "********", consumerSecret: "********", authorizeUrl: "https://account.withings.com/oauth2_user/authorize2", accessTokenUrl: "https://wbsapi.withings.net/v2/oauth2?action=requesttoken", responseType: "code" ) ``` This is more of a workaround, but it works. As such, no modifications are needed in the source code. An alternative would be to introduce a boolean, specifically to accommodate Withings. My preference is to omit such special cases as much as possible. But please give feedback if this workaround is not preferred. **Requirement nr.2:** Requirement nr.2 is already implemented, and doesn't need any changes: https://github.com/OAuthSwift/OAuthSwift/blob/d85964b96dbce94df961f28b996187c835089903/Sources/OAuthSwiftClient.swift#L201 I have tested it, and with these changes, I can successfully authorize with Withings and can also refresh the token. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/OAuthSwift#716
No description provided.