json web token is used for oauth login but it fails with pyJWT library because the "sub" claim is an integer but a string content is specified via RFC7519 by the Internet Engineering Task Force (IETF) .
See also:
Description
Description
Details
Details
Related Changes in Gerrit:
Customize query in gerrit
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | BUG REPORT | Xqt | T380270 test_identity of oauth_tests.TestOauthLoginManger fails with Python 3.9+ | ||
| Resolved | Reedy | T382139 "sub" claim of oauth json web token should be a string |
Event Timeline
Comment Actions
Change #1103328 had a related patch set uploaded (by Reedy; author: Reedy):
[mediawiki/extensions/OAuth@master] UserStatementProvider: Cast 'sub' to be a string
Comment Actions
(We don't have Developer-notice anymore, that would be the appropriate tag here.)
@Reedy do you want to announce the change?
Comment Actions
Change #1103328 merged by jenkins-bot:
[mediawiki/extensions/OAuth@master] UserStatementProvider: Cast 'sub' to be a string
Comment Actions
Change #1106052 had a related patch set uploaded (by Reedy; author: Reedy):
[mediawiki/extensions/OAuth@REL1_43] UserStatementProvider: Cast 'sub' to be a string
Comment Actions
Change #1106053 had a related patch set uploaded (by Reedy; author: Reedy):
[mediawiki/extensions/OAuth@REL1_42] UserStatementProvider: Cast 'sub' to be a string
Comment Actions
Change #1106054 had a related patch set uploaded (by Reedy; author: Reedy):
[mediawiki/extensions/OAuth@REL1_41] UserStatementProvider: Cast 'sub' to be a string
Comment Actions
Change #1106055 had a related patch set uploaded (by Reedy; author: Reedy):
[mediawiki/extensions/OAuth@REL1_39] UserStatementProvider: Cast 'sub' to be a string
Comment Actions
@Reedy not sure about the backports... a similar change in T283456: OAuth identfy endpoint should not expose unconfirmed email address broke lots of things. A breaking API change should probably not go into minor releases?
Comment Actions
I guess the likely fallout from pyJWT is larger. Let's make sure the change is well-announced then.
Comment Actions
Change #1106055 merged by jenkins-bot:
[mediawiki/extensions/OAuth@REL1_39] UserStatementProvider: Cast 'sub' to be a string
Comment Actions
Change #1106054 merged by jenkins-bot:
[mediawiki/extensions/OAuth@REL1_41] UserStatementProvider: Cast 'sub' to be a string
Comment Actions
Suggested Tech News text:
The identity endpoint used for OAuth 1 and OAuth 2 returned a JSON object with an integer in its sub field, which was incorrect (the field must always be a string). This has been fixed; the fix will be deployed to Wikimedia wikis on the week of January 13.
We should also write to mediawiki-announce (about the release backports) and mediawiki-api-announce (about the production API change) as well.
Comment Actions
Change #1106053 merged by jenkins-bot:
[mediawiki/extensions/OAuth@REL1_42] UserStatementProvider: Cast 'sub' to be a string
Comment Actions
Change #1106052 merged by jenkins-bot:
[mediawiki/extensions/OAuth@REL1_43] UserStatementProvider: Cast 'sub' to be a string
Comment Actions
Thanks for the draft! I'd like to add an intro-sentence, explaining who this entry is relevant for. Please confirm if it is accurate to write this? -- "For tool and extension developers who use the OAuth system: [...]"
We should also write to mediawiki-announce (about the release backports) and mediawiki-api-announce (about the production API change) as well.
Side-note: This might still need doing by someone.
Comment Actions
Tool and library developers, I'd say. (A few extension developers too, but those won't be reading Tech News.)
We should also write to mediawiki-announce (about the release backports) and mediawiki-api-announce (about the production API change) as well.
Side-note: This might still need doing by someone.
Uhh sorry forgot about that. mediawiki-api-announce mail here. On second thought I think the issue is not that relevant for mediawiki-announce.
Comment Actions
Yes, 1.40 was EOL in June 2024 [1], so no backports would have been performed as this was basically 6 months after that.
If someone is still using 1.40, they should upgrade. Since this report (and it being fixed), 1.41 and 1.42 are also EOL...