-
Notifications
You must be signed in to change notification settings - Fork 196
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
Check for authorization header. #25
base: master
Are you sure you want to change the base?
Conversation
spec/dummy/app/api/api.rb
Outdated
@@ -26,5 +26,10 @@ class API < Grape::API | |||
request.params.as_json | |||
end | |||
|
|||
desc 'Get Authorization header.', authorizations: { oauth2: [] } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice if this actually did OAuth2 :) I would rename the endpoint either way to oauth2
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can set it up but it'll add the dep of doorkeeper (and activerecord). Okay, sounds good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think a dep is fine, we want this to be closer to the real world.
@dblock Happy to improve these tests w/ feedback but how can we land a fix in Swagger UI? Do you know roughly where the offending code is? |
fdb02c4
to
6155558
Compare
I ended up doing this but was forced to mock doorkeeper tokens which turned into a mess. Decided this was easiest way to mock. Anymore feedback @dblock? |
It appears that Swagger-UI correctly sets an authorization header when added in the interface (api key field). However, if the endpoint has the option "authorizations" set with "oauth2", it will override the value. See ruby-grape#13.
6155558
to
be0e363
Compare
I think as far as tests go this is good. |
Cool, is the next move to open an issue at Swagger-UI? |
I think so. Supposedly once that's fixed there we can verify that this test passes. |
@sunnyrjuneja did you ever manage to find a solution to this issue? I have the same problem from what I can tell and would like to investigate further to try and provide a solution. |
Hey @supagroova excuse my brevity since I'm on my phone. There are some references PRs in repos above. I essentially had to do a few work around but was able to solve my problem. If you're unable to figure it out, I'm happy to chat on Skype or GHangout for your problem. |
Hey @sunnyrjuneja @supagroova! I have somehow managed to get it up and running. What I did was I have changed the way the The solution I have found is that instead of reading it after The working code after changes is: auth_headers = {}
<% GrapeSwaggerRails.options.headers.each_with_index do |(key, value), index| %>
<%=raw "auth_headers['header_#{index}'] = new SwaggerClient.ApiKeyAuthorization('#{CGI.escapeHTML(key)}', '#{CGI.escapeHTML(value)}', 'header');" %>
<% end %>
window.swaggerUi = new SwaggerUi({
url: options.app_url + options.url,
dom_id: "swagger-ui-container",
supportHeaderParams: true,
supportedSubmitMethods: ['get', 'post', 'put', 'delete', 'patch'],
onComplete: function(swaggerApi, swaggerUi){
if('console' in window) {
console.log("Loaded SwaggerUI")
console.log(swaggerApi);
console.log(swaggerUi);
}
$('pre code').each(function(i, e) {hljs.highlightBlock(e)});
},
onFailure: function(data) {
if('console' in window) {
console.log("Unable to Load SwaggerUI");
console.log(data);
}
},
docExpansion: options.doc_expansion,
apisSorter: "alpha",
authorizations: auth_headers
}); You can see the full new If you find it of any interest @dblock, I can prepare a separate PR. |
@matfiz That looks great. Thanks mat! |
@matfiz nice, I like it! I ended up using the latest swagger-ui version and doing the following based on the code found here - https://github.com/swagger-api/swagger-ui/blob/master/dist/index.html#L81 Then I changed it as such: function addApiKeyAuthorization(){
var key = encodeURIComponent($('#input_apiKey')[0].value);
if(key && key.trim() != "") {
apiKeyAuth = new SwaggerClient.ApiKeyAuthorization("Authorization", "Bearer "+key, "header");
window.swaggerUi.api.clientAuthorizations.add("oauth2", apiKeyAuth);
log("added key " + key);
}
} The key difference is that once I changed the key I like your approach too and will try it out as I'd like to use this gem and keep swagger-ui out of my app code. |
@matfiz looking at your code again it would seem to me that the My approach was to let the end user input their api_key into the I'm thinking I might fork the project, update it to the latest version of swagger-ui and then add this functionality. Might be of interest to you guys? |
@supagroova Pls have a look at all the changes I made to In my solution, the What you suggested: I think I was solving a problem a little bit different that yours. I needed the header to be included in the api call to fetch I hope it has clarified :) I am also happy to provide a clean PR with the changes I've described. |
I haven't dug in the discussion above, but I am interested in fixing anything that's broken here, please make pull requests! |
Previous to this update, when I tried to do API-key authorization using headers rather than the query string, Swagger-UI would not send my authorization headers. This update basically makes the authorization options get set AFTER Swagger-UI has finished initializing, which seems to make the system much happier. Changes based on a conversation on a mostly-unrelated pull request, ruby-grape#25
@supagroova You saved my life with your @dblock: I'm not sure how best to make a clean pull request out of this change... there are still some weird issues in the resulting behavior (such as some javascript errors that remain, and the curl field not getting updated), but I think those weird issues might already be present and be related to multipart forms rather than header-based authorization. I suspect an update to the underlying Swagger-UI code might fix some of these issues but I'm a bit out of my depth when it comes to the other consequences. Can you take a look at this commit and tell me if it seems worth trying to make a pull request out of this? Apologies if this has all gotten a bit far afield from the original purpose of this pull request! |
@davidbrewer It took me quite some time to work out that fix, so I'm glad that helped you as well! :-) |
I commented in #48. |
Previous to this update, when I tried to do API-key authorization using headers rather than the query string, Swagger-UI would not send my authorization headers. This update basically makes the authorization options get set AFTER Swagger-UI has finished initializing, which seems to make the system much happier. Changes based on a conversation on a mostly-unrelated pull request, ruby-grape#25
Previous to this update, when I tried to do API-key authorization using headers rather than the query string, Swagger-UI would not send my authorization headers. This update basically makes the authorization options get set AFTER Swagger-UI has finished initializing, which seems to make the system much happier. Changes based on a conversation on a mostly-unrelated pull request, ruby-grape#25
I believe #48 fixes this, I am going to close it. |
It still fails:
Want to take a look with all the recent changes @sunnyrjuneja or @davidbrewer? |
I can take a look this afternoon. I'll block out sometime for 1pm PST. |
Given all the 💰 we pay you you're now totally on a deadline :) |
Hey @dblock I gave a pretty honest look at this. I think I can help but do you mind explaining how to run the test server without running tests? I tried |
You're on the right track, it's cause the default is pointing to the wrong place. Change the URL in the green box to http://localhost:9292. |
It appears that Swagger-UI correctly sets an authorization header when
added in the interface (api key field). However, if the endpoint has
the option "authorizations" set with "oauth2", it will override the
value. See #13.