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.

Sign up for GitHub

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

Jump to bottom

Allow fast fail when mutliple security handlers are provided #1767

Open
sami-sweng opened this issue Oct 31, 2023 · 4 comments · May be fixed by #1778
Open

Allow fast fail when mutliple security handlers are provided #1767

sami-sweng opened this issue Oct 31, 2023 · 4 comments · May be fixed by #1778

Comments

@sami-sweng
Copy link

sami-sweng commented Oct 31, 2023 •
edited

Description

When multiple security handlers are provided, for instance

security:
- api_key: []
- {}
components:
  securitySchemes:
    api_key:
      type: apiKey
      name: X-Auth
      in: header
      x-apikeyInfoFunc: app.apikey_auth

To allow either a token or a non authenticated request, assuming a token is provided, but for instance has a wrong signature, or is expired, it should be possible to reject the request.

Expected behaviour

There should be a mechanism to reject the request without looking for the next provider.

For instance raising an OAuthProblem or returning some specific value.

Actual behaviour

The request is considered non-authenticated and the incorrect token is ignored.

Steps to reproduce

Additional info:

Output of the commands:

  • python --version
  • pip show connexion | grep "^Version\:"
Python 3.10.12
Version: 2.14.2
@RobbeSneyders
Copy link
Member

Thanks @sami-sweng. Looking at the OpenAPI specification, the behavior you suggest makes sense.

The most straightforward way to achieve this behavior would be to fail anytime an authorization header or query parameter is provided for a non-authenticated scheme. Not sure if this behavior matches the OpenAPI spec though.

@RobbeSneyders
Copy link
Member

Looks like it's unclear what the behavior should be: OAI/OpenAPI-Specification#1698

@RobbeSneyders
Copy link
Member

Opened an issue on the OpenAPI-specification repository to ask for clarification: OAI/OpenAPI-Specification#3426

@RobbeSneyders RobbeSneyders linked a pull request Nov 2, 2023 that will close this issue
Open
@sami-sweng
Copy link
Author

Hi @RobbeSneyders Thank you for the reply and for the follow up.

I agree with the sentiment. I was of the idea that the current behavior is actually a good default.
The idea was more to add a way to let the user implement this. When implementing the provider there should be a special value that when returned, would let the lib know that it encountered a fatal error and should not continue. (Or that could be a specific Exception).

I looked at the code and between the v2 and v3 it wasn't clear for me if that would still make sense in the v3, and if so where and how that could be implemented. That's why I didn't open a PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fail on invalid token when checking multiple OR security schemes spec-first/connexion
2 participants
@sami-sweng @RobbeSneyders