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: [email protected]
Reporter: [email protected]
QA Contact: [email protected]
CC: [email protected]
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.
_______________________________________________
Koha-bugs mailing list -- [email protected]
To unsubscribe send an email to [email protected]
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
