[Bug 43375] New: OAuth userinfo_url silently fails to parse JSON when Content-Type has extra parameters (e.g. Microsoft Graph)
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43375 Bug ID: 43375 Summary: OAuth userinfo_url silently fails to parse JSON when Content-Type has extra parameters (e.g. Microsoft Graph) Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Authentication Assignee: koha-bugs@lists.koha-community.org Reporter: tomascohen@gmail.com QA Contact: martin.renvoize@openfifth.co.uk CC: dpavlin@rot13.org Target Milestone: --- When configuring an OAuth Identity Provider whose userinfo_url points to an endpoint that returns a Content-Type header with parameters other than charset (for example, Microsoft Graph API's /v1.0/me, which returns Content-Type: application/json;odata.metadata=minimal;odata.streaming=true;IEEE754Compatible=false;charset=utf-8), Koha::Auth::Client::OAuth::_get_data_and_patron fails to parse the response as JSON and silently falls back to treating the body as URL-encoded form data, resulting in all mapped fields being undef â even though the HTTP request succeeded (200) and the body is valid JSON. Root cause: the content-type check at Koha/Auth/Client/OAuth.pm line 86 is a strict regex that only accepts application/json or text/javascript optionally followed by a single ;charset=... parameter: $tx->res->headers->content_type =~ m!^(application/json|text/javascript)(;\s*charset=\S+)?$! Any additional parameter (common in OData-based APIs like Microsoft Graph) causes this regex to fail, silently routing the response through Mojo::Parameters->new($body)->to_hash instead of $tx->res->json. No error or warning is logged â from the admin's perspective, the identity provider config looks correct, the external IdP call succeeds, but login fails downstream with a generic 'No configuration found for your email domain' or 'External auth user cannot access resource' error. Steps to reproduce: 1. Configure an OAuth Identity Provider with userinfo_url pointing to https://graph.microsoft.com/v1.0/me (with an appropriate User.Read scope and a valid Azure AD/Entra ID app). 2. Map any field (e.g. userid -> onPremisesSamAccountName). 3. Attempt to log in via this provider. 4. Observe the login fails to find/match a patron, despite the Graph API call itself succeeding with correct data. Suggested fix: Relax the content-type check to accept any parameters after the media type, not just charset: $tx->res->headers->content_type =~ m!^(application/json|text/javascript)(;|$)! Test plan: 1. Apply the patch. 2. Run: prove t/db_dependent/Koha/Auth/Client/OAuth.t => SUCCESS (new subtest covering extra content-type parameters passes) 3. Configure an OAuth provider with Microsoft Graph userinfo_url. 4. Verify login works when the response includes extra Content-Type parameters. => SUCCESS -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43375 Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tomascohen@gmail.com Assignee|koha-bugs@lists.koha-commun |tomascohen@gmail.com |ity.org | -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43375 Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43375 Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |Needs Signoff Patch complexity|--- |Trivial patch -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43375 --- Comment #1 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- Created attachment 204063 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204063&action=edit Bug 43375: Regression tests This patch adds a regression test demonstrating that the OAuth userinfo_url response parsing fails when the Content-Type header contains extra parameters beyond charset (e.g. Microsoft Graph API returns application/json;odata.metadata=minimal;odata.streaming=true). The strict regex in _get_data_and_patron only matches Content-Type values with an optional ;charset=... suffix, causing valid JSON responses to be silently misinterpreted as URL-encoded form data. Test plan: 1. Apply this patch 2. Run: $ ktd --shell k$ prove t/db_dependent/Koha/Auth/Client/OAuth.t => FAIL: New subtest fails - email is undef, patron not found 3. Sign off :-D -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43375 --- Comment #2 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- Created attachment 204064 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204064&action=edit Bug 43375: Use Mojo json() with form-data fallback for userinfo parsing This patch simplifies the userinfo response parsing by relying on Mojo::Message::Response->json which decodes JSON regardless of Content-Type header parameters. If JSON decoding fails (returns undef), it falls back to URL-encoded form data parsing. This fixes integration with APIs that return extra Content-Type parameters (e.g. Microsoft Graph returns odata.metadata, odata.streaming, and IEEE754Compatible alongside charset) which previously caused the strict regex to fail and silently misparse the response as form data. Test plan: 1. Apply the regression test (previous patch) 2. Run: $ ktd --shell k$ prove t/db_dependent/Koha/Auth/Client/OAuth.t => FAIL: Subtest fails - Content-Type with extra params not recognized 3. Apply this patch 4. Repeat step 2 => SUCCESS: All tests pass 5. Sign off :-D -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43375 Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gabrielmunoz@theke.io Text to go in the| |This patch makes the release notes| |content-type detection for | |the OAuth2 client more | |robust. The result is more | |robust integration with | |external identity | |providers. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43375 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43375 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #204063|0 |1 is obsolete| | Attachment #204064|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43375 --- Comment #3 from David Nind <david@davidnind.com> --- Created attachment 204065 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204065&action=edit Bug 43375: Regression tests This patch adds a regression test demonstrating that the OAuth userinfo_url response parsing fails when the Content-Type header contains extra parameters beyond charset (e.g. Microsoft Graph API returns application/json;odata.metadata=minimal;odata.streaming=true). The strict regex in _get_data_and_patron only matches Content-Type values with an optional ;charset=... suffix, causing valid JSON responses to be silently misinterpreted as URL-encoded form data. Test plan: 1. Apply this patch 2. Run: $ ktd --shell k$ prove t/db_dependent/Koha/Auth/Client/OAuth.t => FAIL: New subtest fails - email is undef, patron not found 3. Sign off :-D Signed-off-by: David Nind <david@davidnind.com> -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43375 --- Comment #4 from David Nind <david@davidnind.com> --- Created attachment 204066 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=204066&action=edit Bug 43375: Use Mojo json() with form-data fallback for userinfo parsing This patch simplifies the userinfo response parsing by relying on Mojo::Message::Response->json which decodes JSON regardless of Content-Type header parameters. If JSON decoding fails (returns undef), it falls back to URL-encoded form data parsing. This fixes integration with APIs that return extra Content-Type parameters (e.g. Microsoft Graph returns odata.metadata, odata.streaming, and IEEE754Compatible alongside charset) which previously caused the strict regex to fail and silently misparse the response as form data. Test plan: 1. Apply the regression test (previous patch) 2. Run: $ ktd --shell k$ prove t/db_dependent/Koha/Auth/Client/OAuth.t => FAIL: Subtest fails - Content-Type with extra params not recognized 3. Apply this patch 4. Repeat step 2 => SUCCESS: All tests pass 5. Sign off :-D Signed-off-by: David Nind <david@davidnind.com> -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org