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

How to pass scope when using resource owner flow? #88

Open
omerlh opened this issue Jun 28, 2016 · 4 comments
Open

How to pass scope when using resource owner flow? #88

omerlh opened this issue Jun 28, 2016 · 4 comments

Comments

@omerlh
Copy link

omerlh commented Jun 28, 2016

Hey
I've am using this library in our app to request a token based on resource owner flow. My question is - how I should pass the scope? I've finally managed to do it using this code:

 var oauthparams = OAuthAuthorizationGrant.ResourceOwnerPasswordCredentials(username, password).parameters
        oauthparams["scope"] = "red"

        heimdallr.requestAccessToken(grantType: "password", parameters: oauthparams) { result in
            switch result {
            case .Success:
                print("success")
            case .Failure(let error):
                print("failure: \(error)")
            }
        }

But this does not feel right.
In the other hand, if this is the way to do this, maybe consider adding it to the readme, or add an overload (I can create a PR). As far as I know scope is required in this flow...

Thanks
Omer

@bckr
Copy link
Contributor

bckr commented Jul 6, 2016

Hey!

regarding to RFC, passing a scope is optional. Unfortunately we don't support this right now in a more elegant way than you described already. We currently offer two public methods for requesting the access token:

public func requestAccessToken(username username: String, password: String, completion: Result<Void, NSError> -> ())
public func requestAccessToken(grantType grantType: String, parameters: [String: String], completion: Result<Void, NSError> -> ())

Only having had a short look at it, we could think about deprecating those in the long term and just using a single function that takes a OAuthAuthorizationGrant as its parameter like we do here. The only problem that I see here is that we would expose a manual way to refresh the access token. Maybe we can finde a way around this? What do you think?

In the other hand, if this is the way to do this, maybe consider adding it to the readme, or add an overload (I can create a PR).

A pull request would be awesome 👍

@omerlh
Copy link
Author

omerlh commented Jul 7, 2016

Hey,
Thank for you for your response!
What do you think of an extension that received grant type and scope and call to this func?
This will not expose anything that is not public already...

@bckr
Copy link
Contributor

bckr commented Jul 15, 2016

Hey! I think an extension is a nice temporary solution, but for the framework itself I would prefer deprecating the current request functions and introducing a unified one that takes an OAuthAuthorizationGrant. I currently can't find the time to do it myself. Would you like to tackle this in a pull request? Happy to give you pointers in the right direction 😊

@omerlh
Copy link
Author

omerlh commented Jul 26, 2016

Maybe expose only one function that receive grant and params? Or only params as the grant can be part of the params? Than we can add extension methods for specific grants.
What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants