Skip to content

Fix: Handle AttributeError in IntrospectTokenView #1562

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

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

dawidwolski-identt
Copy link

@dawidwolski-identt dawidwolski-identt commented Apr 9, 2025

Description of the Change

Handle AttributeError in get_token_response. If there is no token parameter in introspect endpoints they raise AttributeError.

Checklist

  • PR only contains one change (considered splitting up PR)
  • unit-test added
  • documentation updated
  • CHANGELOG.md updated (only for user relevant changes)
  • author name in AUTHORS

@dawidwolski-identt
Copy link
Author

dawidwolski-identt commented Apr 9, 2025

Contribution guideline says

Make sure to request a review by assigning Reviewer jazzband/django-oauth-toolkit.

but I do not have permission to set assignee.

@dopry
Copy link
Member

dopry commented May 19, 2025

I'm not 100% sure this is the correct handling. Per https://datatracker.ietf.org/doc/html/rfc7662#section-2.3,

Note that a properly formed and authorized query for an inactive or
otherwise invalid token (or a token the protected resource is not
allowed to know about) is not considered an error response by this
specification. In these cases, the authorization server MUST instead
respond with an introspection response with the "active" field set to
"false" as described in Section 2.2.

I'm not sure that a missing token would qualify as properly formed. I feel that a 400 might be the proper response in this case since the request is missing the required 'token' parameter. My instinct says a present, but invalid or blank token, i.e. a body of

token=

would return an active: false, but missing token= altogether would be malformed and we should let the caller know they're sending a malformed request, since there is a bug in their implementation. I feel returning a 200 active: false in the case of a malformed request may give consumers/developers confidence in a broken client implementation.

@dawidwolski-identt
Copy link
Author

@dopry I agree with you. I've changed the response to follow https://datatracker.ietf.org/doc/html/rfc6749#section-5.2

@dopry dopry force-pushed the handle_attribute_error_in_get_token_response branch from 8e17051 to f321e0e Compare June 28, 2025 02:34
@dopry dopry force-pushed the handle_attribute_error_in_get_token_response branch from f321e0e to 6416c38 Compare July 24, 2025 23:46
Copy link

codecov bot commented Jul 27, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.38%. Comparing base (3fad765) to head (6416c38).

Additional details and impacted files
@@           Coverage Diff           @@
##           master    #1562   +/-   ##
=======================================
  Coverage   97.37%   97.38%           
=======================================
  Files          34       34           
  Lines        2212     2214    +2     
=======================================
+ Hits         2154     2156    +2     
  Misses         58       58           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@dopry dopry force-pushed the handle_attribute_error_in_get_token_response branch from 6416c38 to f3c619b Compare August 11, 2025 20:48
Copy link

codecov bot commented Aug 11, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

@merito
Copy link
Contributor

merito commented Aug 11, 2025

@dopry thanks for taking care of this

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.

4 participants