OpenAPI 3.0 support for basic bearer auth security type

[jpettit]

When attempting to use the components.securitySchemes definition in OAPI 3.0 I get the following error. This stubs in basic support and is probably a starting point for 2.0 support (not tested)?

This allows a task to define an auth header as such:

authHeader.tasks.yml

- name: authExampleTest
  spec:
    ...
  call:
    ...
    headers.authorization: 'Bearer TOKEN'
  validate:
    ...

openapi.yml 3.0 example

security:
  - bearerAuth: []

...

components:
  securitySchemes:
    bearerAuth:
      type: http
      scheme: bearer

⢀⠀ 0/1A bug occurred.
Please report an issue on the 'test-openapi-plugin-spec' code repository and paste the following lines:

OS: darwin
node.js: v10.11.0
test-openapi: 38.1.1

TypeError: Cannot read property 'bearerAuth' of undefined
    at getSecParam (/Users/jpettit/dev/github/test-openapi/src/core/spec/start/normalize/params/security.js:33:42)
    at secRefs.map (/Users/jpettit/dev/github/test-openapi/src/core/spec/start/normalize/params/security.js:18:5)
    at Array.map (<anonymous>)
    at getSecParams (/Users/jpettit/dev/github/test-openapi/src/core/spec/start/normalize/params/security.js:17:29)
    at getParams (/Users/jpettit/dev/github/test-openapi/src/core/spec/start/normalize/params/main.js:32:21)
    at getOperation (/Users/jpettit/dev/github/test-openapi/src/core/spec/start/normalize/main.js:34:18)
    at Object.entries.map (/Users/jpettit/dev/github/test-openapi/src/core/spec/start/normalize/main.js:27:5)
    at Array.map (<anonymous>)
    at getOperationsByPath (/Users/jpettit/dev/github/test-openapi/src/core/spec/start/normalize/main.js:26:35)
    at Object.entries.map (/Users/jpettit/dev/github/test-openapi/src/core/spec/start/normalize/main.js:16:5)

[jpettit]

@ehmicky - Could you take a look and lmk?

[jpettit]

This isn't a good solution for checking 2.0 and 3.0 specs. Just throwing up the most basic PR here.

[ehmicky]

Thanks for this PR!

OpenAPI 2.0 is not supported

Currently only OpenAPI 2.0 is supported, which is why neither spec.components nor bearer authentication schemes are supported.

I am unfortunately wondering if adding support for only those two properties is a good idea and I will try to explain why (however thanks again for spending time on this).

Supporting those two properties will only add very partial support for OpenAPI 3.0. If your specification is using OpenAPI 3.0, it will most likely crash because of other OpenAPI 3.0-specific properties.

The current OpenAPI normalization code is 2.0-specific. Instead of mixing OpenAPI 2.0 and 3.0 inside the same code, I think it might be better to separate those into two folders, and a third folder for shared code. To go this road would require a PR adding OpenApi 3.0 as a whole, which is quite a lot of work. This is actually on my todo-list but this might take me some time until I am done. I will update README to make current lack of support clearer.

The alternative would be to add bits and pieces of OpenAPI 3.0 logic into the current OpenAPI 2.0 logic, and splitting it later, which does not seem the right way to go about it.

Solution to your initial issue

Now the good news: it turns out you might actually already be able to use Bearer authentication using a different approach:

This project use OpenAPI to generate random HTTP requests based on the OpenAPI parameters schemas. For example if one of your OpenAPI endpoints has a parameter that is a query variable ?onlyPublic=boolean, HTTP requests will randomly use ?onlyPublic=true or ?onlyPublic=false. For authentication HTTP headers, this randomization does not make much sense, because you most likely want to use a specific value in those headers. I.e. there is nothing really useful in OpenAPI to help generate authentication HTTP headers, you still have to manually specify them.

So the way to use Bearer authentication is simply to ignore OpenAPI and just pass it as (and you noticed it yourself based on your first comment):

call:
  headers.authorization: Bearer TOKEN

Problem

One issue you will encounter is that if your specification is OpenAPI 3.0, it will most likely crash. Until I add support for OpenAPI 3.0, the only way around it is to use a converter like this to transform it to OpenAPI 2.0.

[jpettit]

@ehmicky

Thank you for taking the time to respond. There is much to unpack here. Do you have a better way to contact you to discuss some of these things? Discord? Slack?

[ehmicky]

@jpettit I am not sure I will have time for instant messaging. However would emails work for you?

[jpettit]

@ehmicky It could - however, the persistent state and creation of channel topics in something like Slack is nice and would scale beyond two contributors to a project. What is a good email for you?

[ehmicky]

I appreciate your interest in this project. I just created a Gitter room. However I am going for a hike whole day tomorrow and I will celebrate on Sunday, so I will probably only be available on that chat room on Monday unfortunately.

I can check it between two things during the week-end though (although I will only be able to chat asynchronously).

[ehmicky]

New Gitter room