[PR #691] [MERGED] Custom Server Behavior - Requests & Responses customisation #719

New issue

Closed

opened 2026-03-03 17:29:50 +03:00 by kerem · 0 comments

kerem commented

2026-03-03 17:29:50 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/OAuthSwift/OAuthSwift/pull/691
Author: @juliengdt
Created: 1/27/2022
Status: ✅ Merged
Merged: 1/28/2022
Merged by: @phimage

Base: master ← Head: develop

📝 Commits (3)

f8462b3 Customize request headers and custom path response
bd3166f Add Withings OAuth2 for testing
6f78efd Merge branch 'feature/Dynamic-Keypath' into develop

📊 Changes

5 files changed (+117 additions, -21 deletions)

View changed files

📝 Demo/Common/Services.plist (+7 -0)
📝 Demo/Common/ViewController.swift (+43 -0)
📝 OAuthSwift.xcodeproj/project.pbxproj (+11 -9)
📝 Sources/OAuth2Swift.swift (+29 -8)
📝 Sources/OAuthSwiftClient.swift (+27 -4)

📄 Description

What for ?

As I use OAuthSwift in some projects, I discover that certain OAuth provider may be not aware about being 100% Oauth2 compliant. For example, Withings new OAuth2 provider added some custom behavior, which are breaking changes:

Source: Deprecating access and refresh tokens endpoints (Withings support)

Custom get/refresh-token request parameters

Developer have to inject a custom parameter to tell what you want to do.
For a get/refresh-token request, the parameter is:

key	value	description
action	requesttoken	see https://developer.withings.com/api-reference/#operation/oauth2-getaccesstoken

Custom get/refresh-token response

The get/refresh-token response is now a bit different: datas are encapsulated in an object

before

{
   "access_token": [{string} Your new access_token],
   "expires_in": [{integer} Access token expiry delay in seconds],
   "token_type": [{string] HTTP Authorization Header format: Bearer],
   "scope": [{string} Scopes the user accepted],
   "refresh_token": [{string} Your new refresh_token],
   "userid": [{string} The Withings ID of the user]
}

after

{
  "status": [{integer} Withings API response status (cf. https://developer.withings.com/oauth2/#section/Response-status)],
  "body": {
    "access_token": [{string} Your new access_token],
    "expires_in": [{integer} Access token expiry delay in seconds],
    "token_type": [{string] HTTP Authorization Header format: Bearer],
    "scope": [{string} Scopes the user accepted],
    "refresh_token": [{string} Your new refresh_token],
    "userid": [{string} The Withings ID of the user]
  }
}

How

The goal of this PR is to add the ability to inject some datas, without touching existing behavior.

Custom get/refresh-token request parameters

OAuth2Swift init now support a new parameter, called customAccessTokenParams, which is nil by default.
This parameter will be injected in the oauth client and, if exists, will add this dictionary in the parameter dictionary for get/refresh URL request

example:

let oauthswift = OAuth2Swift(
            consumerKey:    serviceParameters["consumerKey"]!,
            consumerSecret: serviceParameters["consumerSecret"]!,
            authorizeUrl:   "https://account.withings.com/oauth2_user/authorize2",
            accessTokenUrl: "https://wbsapi.withings.net/v2/oauth2",
            responseType:   "code",
            customAccessTokenParams: ["action":"requesttoken"] )

the parameter is optional, so existing code will work as expected:

let oauthswift = OAuth2Swift(
            consumerKey:    serviceParameters["consumerKey"]!,
            consumerSecret: serviceParameters["consumerSecret"]!,
            authorizeUrl:   "https://account.withings.com/oauth2_user/authorize2",
            accessTokenUrl: "https://wbsapi.withings.net/v2/oauth2",
            responseType:   "code" )

Custom get/refresh-token response

OAuth2Swift init now support a new parameter, called customKeypath, which is nil by default.
This parameter will be used in the oauth client and, if exists, will modify the path where to get data (ie token, expiration.. so on) in the JSON response.

example:

let oauthswift = OAuth2Swift(
            consumerKey:    serviceParameters["consumerKey"]!,
            consumerSecret: serviceParameters["consumerSecret"]!,
            authorizeUrl:   "https://account.withings.com/oauth2_user/authorize2",
            accessTokenUrl: "https://wbsapi.withings.net/v2/oauth2",
            responseType:   "code",
            customKeypath: "body")

the parameter is optional, so existing code will work as expected:

let oauthswift = OAuth2Swift(
            consumerKey:    serviceParameters["consumerKey"]!,
            consumerSecret: serviceParameters["consumerSecret"]!,
            authorizeUrl:   "https://account.withings.com/oauth2_user/authorize2",
            accessTokenUrl: "https://wbsapi.withings.net/v2/oauth2",
            responseType:   "code" )

Bonus

In-project test app has been modified to play with tithings oauth2 too, only oauth was playable.

_{🔄 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/691 **Author:** [@juliengdt](https://github.com/juliengdt) **Created:** 1/27/2022 **Status:** ✅ Merged **Merged:** 1/28/2022 **Merged by:** [@phimage](https://github.com/phimage) **Base:** `master` ← **Head:** `develop` --- ### 📝 Commits (3) - [`f8462b3`](https://github.com/OAuthSwift/OAuthSwift/commit/f8462b381bfa7ef2a6bbfd7986bd89c719eb9edf) Customize request headers and custom path response - [`bd3166f`](https://github.com/OAuthSwift/OAuthSwift/commit/bd3166ff69e9ad4f780b44c6a6e1d967c31bf4d7) Add Withings OAuth2 for testing - [`6f78efd`](https://github.com/OAuthSwift/OAuthSwift/commit/6f78efda9a29a2f91627851951e4e2e1452f1418) Merge branch 'feature/Dynamic-Keypath' into develop ### 📊 Changes **5 files changed** (+117 additions, -21 deletions) <details> <summary>View changed files</summary> 📝 `Demo/Common/Services.plist` (+7 -0) 📝 `Demo/Common/ViewController.swift` (+43 -0) 📝 `OAuthSwift.xcodeproj/project.pbxproj` (+11 -9) 📝 `Sources/OAuth2Swift.swift` (+29 -8) 📝 `Sources/OAuthSwiftClient.swift` (+27 -4) </details> ### 📄 Description # What for ? As I use OAuthSwift in some projects, I discover that certain OAuth provider may be not aware about being 100% Oauth2 compliant. For example, Withings new OAuth2 provider added some custom behavior, which are breaking changes: Source: [Deprecating access and refresh tokens endpoints (Withings support) ](https://support.withings.com/hc/en-us/articles/360016745358-Deprecating-access-and-refresh-tokens-endpoints) ### Custom get/refresh-token request parameters Developer **have** to inject a custom parameter to tell what you want to do. For a get/refresh-token request, the parameter is: | key | value | description | |--------|--------------|-----------------------------------------------------------------------------------| | action | requesttoken | see https://developer.withings.com/api-reference/#operation/oauth2-getaccesstoken | ### Custom get/refresh-token response The get/refresh-token response is now a bit different: datas are encapsulated in an object before ``` { "access_token": [{string} Your new access_token], "expires_in": [{integer} Access token expiry delay in seconds], "token_type": [{string] HTTP Authorization Header format: Bearer], "scope": [{string} Scopes the user accepted], "refresh_token": [{string} Your new refresh_token], "userid": [{string} The Withings ID of the user] } ``` after ``` { "status": [{integer} Withings API response status (cf. https://developer.withings.com/oauth2/#section/Response-status)], "body": { "access_token": [{string} Your new access_token], "expires_in": [{integer} Access token expiry delay in seconds], "token_type": [{string] HTTP Authorization Header format: Bearer], "scope": [{string} Scopes the user accepted], "refresh_token": [{string} Your new refresh_token], "userid": [{string} The Withings ID of the user] } } ``` # How The goal of this PR is to add the ability to inject some datas, **without touching existing behavior**. ### Custom get/refresh-token request parameters OAuth2Swift init now support a new parameter, called `customAccessTokenParams`, which is nil by default. This parameter will be injected in the oauth client and, if exists, will add this dictionary in the parameter dictionary for get/refresh URL request example: ``` let oauthswift = OAuth2Swift( consumerKey: serviceParameters["consumerKey"]!, consumerSecret: serviceParameters["consumerSecret"]!, authorizeUrl: "https://account.withings.com/oauth2_user/authorize2", accessTokenUrl: "https://wbsapi.withings.net/v2/oauth2", responseType: "code", customAccessTokenParams: ["action":"requesttoken"] ) ``` the parameter is optional, so existing code will work as expected: ``` let oauthswift = OAuth2Swift( consumerKey: serviceParameters["consumerKey"]!, consumerSecret: serviceParameters["consumerSecret"]!, authorizeUrl: "https://account.withings.com/oauth2_user/authorize2", accessTokenUrl: "https://wbsapi.withings.net/v2/oauth2", responseType: "code" ) ``` ### Custom get/refresh-token response OAuth2Swift init now support a new parameter, called `customKeypath`, which is nil by default. This parameter will be used in the oauth client and, if exists, will modify the path where to get data (ie token, expiration.. so on) in the JSON response. example: ``` let oauthswift = OAuth2Swift( consumerKey: serviceParameters["consumerKey"]!, consumerSecret: serviceParameters["consumerSecret"]!, authorizeUrl: "https://account.withings.com/oauth2_user/authorize2", accessTokenUrl: "https://wbsapi.withings.net/v2/oauth2", responseType: "code", customKeypath: "body") ``` the parameter is optional, so existing code will work as expected: ``` let oauthswift = OAuth2Swift( consumerKey: serviceParameters["consumerKey"]!, consumerSecret: serviceParameters["consumerSecret"]!, authorizeUrl: "https://account.withings.com/oauth2_user/authorize2", accessTokenUrl: "https://wbsapi.withings.net/v2/oauth2", responseType: "code" ) ``` # Bonus In-project test app has been modified to play with tithings oauth2 too, only oauth was playable. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>