Skip to content

Support for Bearer token in the header for OAuth2 #98

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

Open
skasturi opened this issue Nov 30, 2016 · 8 comments
Open

Support for Bearer token in the header for OAuth2 #98

skasturi opened this issue Nov 30, 2016 · 8 comments
Milestone

Comments

@skasturi
Copy link

In OAuth2, I am not able to get the Bearer token set in the header automatically. How do I get it working?

@mission-liao
Copy link
Member

mission-liao commented Dec 1, 2016

I'm not familiar with Bearer token, and it seems this part is more precisely defined in 3.0 spec (OAI/OpenAPI-Specification#807).

Right now OAuth2 supports in pyswagger is users need to provide the final token (to pyswagger.Security) after finishing the OAuth2 flow.

Reply @skasturi
The swagger.json should at least contain this definition (this is the minimum requirement of server support OAuth2 token in Bearer format):

...
"securityDefinitions":{
   "your_token":{
      "type":"apiKey",
      "in":"header",
      "name":"Authorization"
   }
}
...

And once you get the token, you need to update it to pyswagger.Security object with what Bearer token described

import Security from pyswagger
your_token = xxxxxxxxx # assume you get the Bearer token somewhere
s = Security(app)
s.update_with('your_token', 'Bearer ' + your_token)

If you've done those and still can't make Bearer token set in header automatically, please let me know, it's definitely a bug.

@skasturi
Copy link
Author

skasturi commented Dec 18, 2016

Hi @mission-liao Thank you very much for you response. What you mentioned is what I am trying to do to hack this out. But I believe we should support this in pyswagger natively. As you mentioned looks like it is part of v 3.0 spec. But, I guess it is simple enough to be added even now. What do you think?

@mission-liao
Copy link
Member

I think yes, I can add those defined in 3.0 to current implementation of pyswagger, since they'll be supported later.

@mission-liao mission-liao added this to the v0.8.25 milestone Dec 19, 2016
@erikpotterbsx
Copy link

erikpotterbsx commented Dec 19, 2016

Thanks, I need this too

My temporary solution is to manually add the token to the header:

token = get_token()  # get the token somehow

client = Client()
client._Client__s.headers['Authorization'] = 'Bearer ' + token

@mission-liao
Copy link
Member

mission-liao commented Dec 23, 2016

@erikpotterbsx @skasturi what I prefer to provide is to support partial of 3.0 spec in current pyswagger, that is, pyswagger can read the spec contains

scheme: "bearer"

and automatically prefix "Bearer " with token when assigned to "Authorization" in header.

However, I guess it's not the solution you need because the swagger.json provided by service also needs to be modified to "partially fit" to Open API 3.0 spec.

I guess what you need is to have a special method in pyswagger.Security, will automatically prefix "Bearer " when providing tokens, right?

@mission-liao
Copy link
Member

Here is my proposal:

  • a new function would be added to pyswagger.Security to prefix 'bearer ' automatically.
  • when that function is used, a flag would be added to the pyswagger.Security to indicate that object can't be used with OpenAPI 3.0 (service supports Open API 3.0 should use new schema to declare this part)

@mission-liao
Copy link
Member

prefer to postpone this issue, because there is little thing we can do at this moment:

we can provide a special method (or a dedicated class) for users to specifically set a Bearer token, however, it's not a big imporvement for usage because users can still set a Bearer token by prefixing the token with "Bearer " by themselves.

@mission-liao mission-liao removed this from the v0.8.25 milestone Jan 9, 2017
@skasturi
Copy link
Author

Thanks for the patience @mission-liao. I think we can live with this for now while support for 3.0 is being implemented.

@mission-liao mission-liao reopened this Apr 15, 2017
@mission-liao mission-liao added this to the v0.9.1 milestone Apr 15, 2017
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

3 participants