2085553 - Github logins are failing with JSON error after recent changes to Bugzilla

Status: RESOLVED FIXED

(bugzilla.mozilla.org :: Extensions, defect, P1)

Description

[David Lawrence [:dkl]]

Users are unable to log in to bugzilla.mozilla.org using the "Log in with GitHub" option. Every attempt fails with the following internal error:

You are using Bugzilla's messaging functions incorrectly. You passed in the string 'Unable to parse JSON response'. The correct use is to pass in a tag, and define that tag in the file messages.html.tmpl.
If you are a Bugzilla end-user seeing this message, please save this page and send it to [e-mail].
Bugzilla has suffered an internal error:
Received unexpected response from GitHub: Unable to parse JSON response

Importantly, the OAuth authorization itself appears to succeed on GitHub's side: They receive the confirmation email from GitHub ("A third-party OAuth application has been added to your account") stating that the application bugzilla.mozilla.org with user:email scopes was authorized, and it now appears in their GitHub authorized OAuth applications. So GitHub grants the token, but Bugzilla fails afterwards with "Unable to parse JSON response" — the failure seems to occur when Bugzilla exchanges or reads the token/identity response from GitHub, not during user authorization.

This suggests the problem is on the Bugzilla side of the handshake (e.g. an unexpected response format from GitHub's API, or an error page being returned where JSON is expected), rather than anything in their account configuration.

Comment 1

[David Lawrence [:dkl]]

What's going on (2 bugs stacked)

1. The real failure is hidden. _handle_response in extensions/GitHubAuth/lib/Client.pm:67 tries to parse the body as JSON before it checks is_success. So if GitHub (or a proxy, or LWP itself) sends back a non-JSON error, we throw "Unable to parse JSON response" and lose the HTTP status and body.
2. The garbled wrapper is a variable-name clash. The error passes {message => ...}. But global/header.html.tmpl:47 treats any message variable as a message tag and runs messages.html.tmpl, which then complains it isn't a known tag. This has been there for years. It only shows up now because this error path started firing.

I can't tell from the code alone which call is failing: the token exchange, or /user/emails. One thing stands out: when LWP fails on the client side (TLS or proxy trouble), it returns a fake 500 with a plain-text body. That would produce exactly this error.

Proposed fix (1 file + 1 template, ~15 lines)

1. Check is_success first, then parse JSON.
2. Put the HTTP status and a short, HTML-filtered piece of the body into the error, so the next failure tells us the cause.
3. Rename the template variable from message to reason so the header doesn't grab it.
4. Add use LWP::UserAgent; explicitly. Right now it only works because some other module happens to load it first.
5. Add a test under extensions/GitHubAuth/t/ with a mocked UA covering the non-JSON and non-2xx cases.

Tradeoff: this makes the failure readable but may not be the whole fix. If the root cause is TLS, a proxy, or a GitHub-side change, the new error will name it, and that may need a second small change.

Comment 2

[BMO Github Automation]

Attachment: [mozilla/bmo] Bug 2085553 - Github logins are failing with JSON error after recent changes to Bugzilla (#2797)

(via GitHub webhook, authenticated as shared-secret)

Comment 3

[BMO Github Automation]

Authored by https://github.com/dklawren
https://github.com/mozilla/bmo/commit/19001c94d21676073cdee4bd98f21f0f606a3665
[master] Bug 2085553 - Github logins are failing with JSON error after recent changes to Bugzilla

(via GitHub webhook, authenticated as shared-secret)