Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Appearance settings

Custom Server Behavior - Requests & Responses customisation #691

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 3 commits into from
Jan 28, 2022
Merged

Custom Server Behavior - Requests & Responses customisation #691

merged 3 commits into from
Jan 28, 2022

Conversation

juliengdt
Copy link

@juliengdt juliengdt commented Jan 27, 2022 •
edited
Loading

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.

@juliengdt
Copy link
Author

Will fix #663

@juliengdt
Copy link
Author

Is an enhancement of #675

cc @BJAdeGraaf

@juliengdt
Copy link
Author

@phimage @dongri don't hesitate if you have any questions.

Thanks anyway ✌️

@juliengdt juliengdt marked this pull request as ready for review January 27, 2022 08:42
@phimage
Copy link
Member

phimage commented Jan 27, 2022

seems good 👍

yes oauth universal client lib must deal with too much special case 😢

@VincentDurandChewbi
Copy link

+1

@phimage phimage merged commit fb65e91 into OAuthSwift:master Jan 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@juliengdt @phimage @VincentDurandChewbi
Morty Proxy This is a proxified and sanitized view of the page, visit original site.