starred/OAuthSwift

Fork 0

mirror of https://github.com/OAuthSwift/OAuthSwift.git synced 2026-04-26 12:45:52 +03:00

[GH-ISSUE #221] Feature request: Custom headers for OAuth2 #121

New issue

Closed

opened 2026-03-03 16:45:52 +03:00 by kerem · 5 comments

kerem commented

2026-03-03 16:45:52 +03:00

Owner

Originally created by @jwrigh26 on GitHub (Apr 5, 2016).
Original GitHub issue: https://github.com/OAuthSwift/OAuthSwift/issues/221

I've been using your library for a while and in doing so, I have found the need to make 2 file changes in the source code to allow for custom headers. This allows me to use this library with APIs like MapMyRun, etc that require specific header parameters.

Would you be open to the possibility in looking at a Pull Request from me or just adding this feature.

Currently I made changes to the OAuth2Swift class to allow passing in optional custom headers during init. And then OAuthSwiftCredential I check for those headers in the the makeHeader:: method.

The benefits of doing this would help make the library less rigid to 3rd party APIs that do not follow exactly OAuth 2 guidelines.

Originally created by @jwrigh26 on GitHub (Apr 5, 2016). Original GitHub issue: https://github.com/OAuthSwift/OAuthSwift/issues/221 I've been using your library for a while and in doing so, I have found the need to make 2 file changes in the source code to allow for custom headers. This allows me to use this library with APIs like MapMyRun, etc that require specific header parameters. Would you be open to the possibility in looking at a Pull Request from me or just adding this feature. Currently I made changes to the OAuth2Swift class to allow passing in optional custom headers during init. And then OAuthSwiftCredential I check for those headers in the the makeHeader:: method. The benefits of doing this would help make the library less rigid to 3rd party APIs that do not follow exactly OAuth 2 guidelines.

kerem

2026-03-03 16:45:52 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-03-03 16:45:52 +03:00

Author

Owner

@phimage commented on GitHub (Apr 6, 2016):

when did you need to use header parameters?
when authenticate?
if yes, I will check how to do this, maybe some code could be shared with #198
if not, OAuthSwiftClient methods have already headers "parameters"

@phimage commented on GitHub (Apr 6, 2016): when did you need to use header parameters? when authenticate? if yes, I will check how to do this, maybe some code could be shared with #198 if not, OAuthSwiftClient methods have already headers "parameters"

kerem commented

2026-03-03 16:45:53 +03:00

Author

Owner

@jwrigh26 commented on GitHub (Apr 6, 2016):

As stated above APIs like Map My Run and some other non-public APIs we use in our projects require various parameters in the headers. I have forked your project and already implemented changes. I agree, for the most part your library handles most cases. For the few cases where additional parameters are needed during authentication it would be great to be able to include headers.

My changes in my forked branch include two connivence initializers in OAuth2Swift that pass a string dictionary of headers over to the OAuthSwiftCredential class. And in OAuthSwiftCredential class I made a minor change in makeHeaders:: to check to see if a public optional var called oauth2_headers is not nil. If so it uses that dictionary in place of the default parameters.

See the links below for actual code from my forked branch.

OAuthSwiftCredential changes
Line 54, 110

OAuth2Swift changes
Line 28-39

Totally open in including these changes or somehow incorporating them with #198

@jwrigh26 commented on GitHub (Apr 6, 2016): As stated above APIs like Map My Run and some other non-public APIs we use in our projects require various parameters in the headers. I have forked your project and already implemented changes. I agree, for the most part your library handles most cases. For the few cases where additional parameters are needed during authentication it would be great to be able to include headers. My changes in my forked branch include two connivence initializers in OAuth2Swift that pass a string dictionary of headers over to the OAuthSwiftCredential class. And in OAuthSwiftCredential class I made a minor change in **makeHeaders::** to check to see if a public optional var called **oauth2_headers** is not nil. If so it uses that dictionary in place of the default parameters. See the links below for actual code from my forked branch. [OAuthSwiftCredential changes](https://github.com/jwrigh26/OAuthSwift/blob/enhancement-headers/OAuthSwift/OAuthSwiftCredential.swift) Line 54, 110 [OAuth2Swift changes](https://github.com/jwrigh26/OAuthSwift/blob/enhancement-headers/OAuthSwift/OAuth2Swift.swift) Line 28-39 Totally open in including these changes or somehow incorporating them with #198

kerem commented

2026-03-03 16:45:53 +03:00

Author

Owner

@phimage commented on GitHub (Apr 6, 2016):

I see the closed PR, and you don't respond to my question... I will not read documentation of oauth provider, no time for this

I am not agree to create an other init because

you can add optional parameters to an existant init
credential is affected, not oauth2swift object, so after init add headers in credential directly...

Then we can also generalize to oauth1 . So we can have a var(name to find) which replace the headers always if defined. Or maybe we can just add some headers after.. Or add a callback handler, which fill the header for custom use (I think this could be better)

But I need to understand when custom headers is necessary... and why you can specify header in oauthclient methods parameters

@phimage commented on GitHub (Apr 6, 2016): I see the closed PR, and you don't respond to my question... I will not read documentation of oauth provider, no time for this I am not agree to create an other init because - you can add optional parameters to an existant init - credential is affected, not oauth2swift object, so after init add headers in credential directly... Then we can also generalize to oauth1 . So we can have a var(name to find) which replace the headers always if defined. Or maybe we can just add some headers after.. Or add a callback handler, which fill the header for custom use (I think this could be better) But I need to understand when custom headers is necessary... and why you can specify header in oauthclient methods parameters

kerem commented

2026-03-03 16:45:53 +03:00

Author

Owner

@jwrigh26 commented on GitHub (Apr 6, 2016):

My apologies for not answering your questions directly.

Custom headers are necessary during authorization.
It would be great to specify headers in the OAuthSwiftClient. I did not know we could manipulate this object. I was under the assumption that an OAuthSwift class created it.

I like your ideas about generalizing it or better yet a callback handler.

@jwrigh26 commented on GitHub (Apr 6, 2016): My apologies for not answering your questions directly. 1. Custom headers are necessary during authorization. 2. It would be great to specify headers in the OAuthSwiftClient. I did not know we could manipulate this object. I was under the assumption that an OAuthSwift class created it. I like your ideas about generalizing it or better yet a callback handler.

kerem commented

2026-03-03 16:45:53 +03:00

Author

Owner

@phimage commented on GitHub (Jul 7, 2016):

I have added an headersFactory argument into credential (oauthswift.client.credential.headersFactory)
which conform to the new protocol OAuthSwiftCredentialHeadersFactory

Setting your own factory allow you to change the way the headers are created

@phimage commented on GitHub (Jul 7, 2016): I have added an `headersFactory` argument into credential (`oauthswift.client.credential.headersFactory`) which conform to the new protocol `OAuthSwiftCredentialHeadersFactory` Setting your own factory allow you to change the way the headers are created

kerem referenced this issue

2026-03-03 16:49:16 +03:00

[PR #121] [MERGED] Add enum for HTTP Method and OAuth protocol version #523