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.

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

Header matching is not case-insenitive as defined by RFC 2616 #472

Closed
3 tasks done
dadrus opened this issue Feb 3, 2023 · 0 comments · Fixed by #483
Closed
3 tasks done

Header matching is not case-insenitive as defined by RFC 2616 #472

dadrus opened this issue Feb 3, 2023 · 0 comments · Fixed by #483
Labels
bug Something isn't working

Comments

@dadrus
Copy link
Owner

dadrus commented Feb 3, 2023

Preflight checklist

  • I agree to follow this project's Code of Conduct.
  • I have read and am following this repository's Contribution Guidelines."
  • I could not find a solution in the existing issues, docs, nor discussions.

Describe the bug

Header matching happens in the error pipeline to select the required error handler. Unfortunately that process does not take case-insensitivity into account. That leads to wrong error handlers kicking in resulting in unexpected behavior.

How can the bug be reproduced

  1. configure e.g. the following authenticator, unifier, error handlers and a default rule in the rules section:
mechanisms:
  authenticators:
    - id: unauthorized_authenticator
      type: unauthorized
  unifiers:
    - id: noop
      type: noop
  error_handlers:
   - id: default
     type: default
   - id: redirect_somewhere
     type: redirect
     config:
       to: http://127.0.0.1:8080/some-endpoint
       when:
         - error:
             - type: authentication_error
           request_headers:
             accept:
               - 'text/plain'

default:
  methods:
    - GET
  execute:
    - authenticator: unauthorized_authenticator
    - unifier: noop
  on_error:
    - error_handler: redirect_somewhere
  1. start heimdall in the decision mode by making use of the above config
  2. send curl requests to the decision endpoint by adding an Accept: text/plain header. The response will be 401 Unauthorized.
  3. send curl requests to the decision endpoint by adding an accept: text/plain header. The response will be a 302 with a the location header set to the configured url.

For both requests redirect is expected.

Relevant log output

No response

Relevant configuration

No response

Version

0.6.0-alpha

On which operating system are you observing this issue?

Linux

In which environment are you deploying?

None

Additional Context

No response

@dadrus dadrus added the bug Something isn't working label Feb 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant