Howdy, I understand this has been the source of some confusion so I'll try to document the behavior here.
First, the UI uses jquery which *requires* for CORS support that the server respond to OPTIONS requests with the header keys that are going to be sent. What does that mean?
1) If you're sending a header called 'api', your server needs to respond with a 2xx code when queried to see if it supports that header param.
2) If you're sending headers as params inside operations, you need to support those header names as well.
Specifically, for any request to the server, you should see something like this:
Access-Control-Request-Headers:
foo, accept, magic, bar, api_key, origin, content-type
In this API, I'm passing "api_key", "foo", "bar" as header params. Without those headers being supported by the server, the UI will *not* work. Note that "*" as a header name doesn't seem to work currently (at least on Chrome on mac, Version 27.0.1430.0 at least)
Next, the UI has a field for an api key. That can be named *anything you like* as long as it's configured in the UI. For example, while the default is "api_key", say you want it to be "specialToken", and pass it as a header param, not query string. You would need to do the following:
1) configure the key name when initializing swagger ui:
apiKey:"specialToken"
2) enable header params:
supportHeaderParams: true
3) ensure your server responds to the OPTIONS request, per above. Now the value "specialToken" will be passed--if non blank--on every request.
Finally, you can add *any* headers to be passed by default to swagger-ui. Those can be configured dynamically as part of an oauth dance or whatever you like--this is simply done by the following.
1) When initializing swagger-ui, set the headers like such:
headers: {"secretToken","abc123", "sessionId", "def456"}
2) ensure headers are supported
3) ensure your server responds to the "secretToken" and "sessionId" params
Hopefully this clarifies the header support, please post back if not!
Tony