Swagger-UI calls don't work with JWT auth

[PierreBesson]

When using swagger UI on an application that uses JWT as authenticationType, the "Try it out" feature fails and return something like this:

{
  "timestamp": "2016-02-09T13:22:08.868+0000",
  "status": 401,
  "error": "Unauthorized",
  "message": "Access Denied",
  "path": "/api/foos"
}

It seems that some people have already managed to solve this problem (see this swagger-ui issue).

I plan to do a PR to fix that. What I will do is get the JWT token from localStorage and follow instructions from the previous link.
Please tell me if you have any thought on this.

[PierreBesson]

OK, I just got it to work. Just added:

function addApiKeyAuthorization() {
  var key = JSON.parse(localStorage.getItem("ls.authentication-token"));
  if (key && key.trim() != "") {
    var apiKeyAuth = new SwaggerClient.ApiKeyAuthorization("Authorization", "Bearer " + key, "header");
    window.swaggerUi.api.clientAuthorizations.add("bearer", apiKeyAuth);
    log("Set bearer token: " + key);
  }
}

Really JWT is magic, so easy 😃 !

[PierreBesson]

Also, may I suggest an improvement, currently we don't have the "api_key" field on our Swagger-Ui (see for example: http://petstore.swagger.io/). It would be nice at least for JWT to be able to set different tokens directly in Swagger-UI and then try the APIs with those tokens. This is interesting for the "granular security feature of JWT.

[gmarziou]

@PierreBesson

All changes we make to swagger-ui/_index.html have to be manually merged when we update swagger-ui, this is why we don't have yet the api_key input field but I like your idea.

This manual merge is a bit painful at the moment. I'm wondering whether this could be easier by externalizing our JS code from the index.html

[cbornet]

@PierreBesson the code for the swagger page comes from springfox (https://github.com/springfox/springfox/tree/master/springfox-swagger-ui/src/web). I have removed the api_key text box on purpose but it is easy to put it again.

[PierreBesson]

@gmarziou I see the problem that would arise when updating swagger-ui. But externalizing the js will not be enough to prevent all merge conflicts.

I have an idea on how we could handle this but maybe it's a bit crazy.
So currently we go to http://localhost:8080/#/docs and there we have an iframe to swagger-ui/index.html. So I think that we could inject our custom js into this iframe (with the onload="" property on the iframe element) and then we could use the vanilla swagger-ui from springfox. What do you think ?

[PierreBesson]

Oh and this means that we could be using the webjar.

[gmarziou]

The index.html provided by springfox is not the original one from swagger-ui.
In particular, it includes springfox.js

[cbornet]

springfox.js is just the js code that was extracted from the original index.html and on which they added some special "springfox" features (ui conf from java bean, docket group selection, ...)
I guess the people from springfox will maintain this code in phase with swagger-ui.

[PierreBesson]

But shouldn't we move to springfox's swagger-ui ?
It can handle api_keys and security auth code for us (see springfox.js). We will have to set a custom Springfox security config ine java code like here and then swagger-ui will be configured from it. This way we stick with sprinfox's swagger-ui client and don't need to merge on every release.

[cbornet]

@PierreBesson But the apiKey we want to pass (for instance JJWT or CSRF token) comes from javacript, not from java and is dynamic so it can't come from a bean

[cbornet]

Maybe we could PR to springfox to add the possibility to pass the api key and api key name by url

[PierreBesson]

@cbornet Oh I see...

Maybe we could PR to springfox to have the possibility to add the api key by url

Yes it would be nice to have, but would it be enough to handle all our authentication schemes.

[cbornet]

Whatever the auth type, we always call SwaggerClient.ApiKeyAuthorization() so that should be OK.
On the other hand, the security impact of passing auth data to an i-frame by url should probably be studied.

[gmarziou]

This is why we enabled it only for dev.
An alternative would be to get rid of the iframe and use an angular directive on top of swagger, there are few of them.

[PierreBesson]

If we would like to customize swagger-ui a lot, it might be interesting to follow this idea. A second JHipster intern will arrive next week and he has some angular experience, he could help me to develop this. Then we could extends swagger-ui functionality for the gateway, for example to add a way to sort the available API, arrange them by folder or search the available resources)...

[gmarziou]

Sounds good, the directive I tried 3 months ago was angular-swagger-ui. I just reviewed it and it is not very active, I checked also 2 others who are even less active.

So I'm afraid that these projects may not offer very good support and not migrate to angular 2 soon.

[deepu105]

I dont think it will be hard to write a directive if our own. Its better
than depending on non active projects
On 11 Feb 2016 05:31, "Gaël Marziou" notifications@github.com wrote:

Sounds good, the directive I tried 3 months ago was angular-swagger-ui
https://github.com/Orange-OpenSource/angular-swagger-ui. I just
reviewed it and it is not very active, I checked also 2 others who are even
less active.

So I'm afraid that these projects may not offer very good support and not
migrate to angular 2 soon.

—
Reply to this email directly or view it on GitHub
#2836 (comment)
.