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

GH-42: Fix: Middleware overhandling exceptions #44

Merged
merged 12 commits into from
Aug 19, 2024

Conversation

vokimon
Copy link
Contributor

@vokimon vokimon commented Jul 25, 2024

Move middleware error handling from __call__ to authenticate and make it more specific.

Motivation:

This pull request attempts to fix issue GH-42: Middleware exception handling now intercepts any exception raised by user code as AuthenticationError 401, even when the entry point requires no Authentication. This behavior masks coding errors in user code while developing, and bug detection in logs while in production.

The behaviour was reintroduced in aa8f4b3

Removing it from __call__ fixes the problem, but then exceptions really related to authentication must be handled. My first proposal is to move the handling to autenticate(). Instead of wide range handling, I opted to specific handling, just not to maks bugs and issues. But i just detected the JWT problems handling. Not sure if we have to deal any other but as authentication.

A second problem is how it is to be handled. I took as reference the previous PR on JWT expiration, and raised OAuth2AuthenticationError. The problem with that is that such exception is not HTTPException and FastApi / Starlette does not handle it as intended.

All Submissions:

  • Have you followed the guidelines in our Contributing document?
  • Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Changes to Core Features:

  • Have you added an explanation of what your changes do and why you'd like us to include them?
  • Have you updated the documentation related to the changes you have made? -> Wait to have a final solution.
  • Have you written new tests for your core changes, as applicable?
  • Have you successfully run tests with your changes locally?

- Unintended errors in code should be 500
- Non Http custom exceptions should be 500
- Handled exceptions should use handler (and be 418 in this case)

But all of them are reported as 401 Unauthorized even
when the entrypoint does not requires authorization.
I added a case of exception that should be handled:
as auth errors: jwt validation errors

Using same approach as expiration check,
but maybe it should be a HttpException in order
to be properly handled both by fastapi and users.

Also unexpected errors are not transformed to
500 either on the test setup. Maybe because we are
not using Fastapi TestClient.
- Removed the generic error handling in __call__()
- Introduced specific error handling inside authenticate()
  for jwt decoding.
    - One use of jwt is in token generation in core,
      but in this case it won't be a authorization error
      but maybe a configuration one, we should see
      the details in logging or debugging platforms.
- For sure, other authorization errors caught previously
  as Exception now run on the wild.
  Review required on that.
vokimon and others added 8 commits July 30, 2024 18:26
That is:
- raising starlette.authentication.AuthenticationError
- providing an on_error callback turning starlet 400 into 401
  to keep same api
- letting the user provide their own on_error when instantiating
  the middleware.
- Use `default_on_error` instead of defining new one
@ArtyomVancyan ArtyomVancyan marked this pull request as ready for review August 18, 2024 18:24
@ArtyomVancyan ArtyomVancyan merged commit e388257 into pysnippet:master Aug 19, 2024
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

🐛 Bug Report - Catching all exceptions makes error handling and application debugging imposible
2 participants