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

Implement Authentications for Swagger 2.0 #764

Closed
avianey opened this issue Dec 5, 2014 · 8 comments
Closed

Implement Authentications for Swagger 2.0 #764

avianey opened this issue Dec 5, 2014 · 8 comments

Comments

@avianey
Copy link

avianey commented Dec 5, 2014

In the swagger-ui default index.html page, it would be great if we can switch to/from the defaut api_key input text field to username/passwaord inputs to allow basic auth. It's only possibile to use ApiKeyAuthorization. A <select> would be great to switch between ApiKeyAuthorization and PasswordAuthorization with something like this :

$('#input_username, #input_password').change(function() {
      var username = $('#input_username')[0].value;
      var password = $('#input_password')[0].value;
      if(username && username.trim() != "" && password && password.trim() != "") {
        window.authorizations.add("key", new PasswordAuthorization("basic_auth", username, password));
      }
    })
@fehguy fehguy added this to the v2.1.0-M1 milestone Dec 29, 2014
@fehguy
Copy link
Contributor

fehguy commented Dec 29, 2014

We'll be letting the spec determine what security definitions are supported, and the UI will reflect it in 2.1.0-M1.

@avianey
Copy link
Author

avianey commented Dec 30, 2014

👍

@fehguy
Copy link
Contributor

fehguy commented Jan 31, 2015

Moving to M2

@fehguy fehguy modified the milestones: v2.1.0-M2, v2.1.0-M1 Jan 31, 2015
@mohsen1
Copy link
Contributor

mohsen1 commented Mar 17, 2015

We can keep the header the way it is and detect a colon in the field. If that's present we use that for basic auth. (username:password)
The limitation is, if an API key has colon in it it will get treated as basic auth.

What do you think @fehguy
screen shot 2015-03-17 at 1 29 59 pm

@fehguy
Copy link
Contributor

fehguy commented Mar 19, 2015

I think we hit this up over IRC, but my preference is as follows:

  • for each securityDefinition render a login button in place of the key text edit box
  • for each type of securityDefinition, render a different button style. The types (off the top of my head) are:
    • basic auth
    • api key
    • oauth (3 flows)
  • when clicking any of the buttons, the appropriate authentication form is presented. For oauth, it'd look like this:

image

After applying, the window.swaggerUi.authorizations will be updated.

@mohsen1 mohsen1 self-assigned this Mar 19, 2015
@mohsen1 mohsen1 changed the title Allow switch from api_key to basic auth in header UI Implement Authentications for Swagger 2.0 Mar 19, 2015
@fehguy fehguy modified the milestones: v2.1, v2.1-M2 Mar 26, 2015
@jahlborn
Copy link

jahlborn commented Apr 8, 2015

I'm confused by the comments here. The original issue seems to request basic auth for downloading the swagger spec (which we would definitely like to have). but the comments seems to imply determining the security available based on the swagger spec (which wouldn't yet be available)... am i misunderstanding something?

@webron webron modified the milestones: v2.1.2, v2.1.3 Sep 2, 2015
@joerocklin
Copy link

Seems like this keeps getting kicked down the road. Is anyone working on this at all?
I've been able to modify the index.html (in the released v2.1.3) to use the Authorization header, but it seems to only apply to all of the paths which do not have a security section defined - the opposite of what I would expect. (The online swagger editor seems to have the correct behavior).

Edit to add: I managed to get things working without changing much. It seems that either I misunderstood the documentation or the documentation needs a little improvement. I'll see if I can find some way of describing the pieces that finally clicked in place for me to understand what needed to be done.

@fehguy
Copy link
Contributor

fehguy commented Aug 23, 2016

See 2.2.1, this is now all dynamic.

@fehguy fehguy closed this as completed Aug 23, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants