Skip to content

Bug 2061445 - Re-land the native Mojo Bugzilla (system info) REST resource - #2828

Merged
dklawren merged 3 commits into
mozilla:masterfrom
Xzzz:bug-2061445
Nov 13, 2026
Merged

dklawren merged 3 commits into
mozilla:masterfrom
Xzzz:bug-2061445

Conversation

@Xzzz

@Xzzz Xzzz commented Nov 12, 2026

Copy link
Copy Markdown
Collaborator

Summary

Re-lands the native Bugzilla::API::V1::Bugzilla controller (/rest/version, /extensions, /timezone, /time, /jobqueue_status), reverted in ef9e9b0 because a monitoring service calls /rest/jobqueue_status with ?api_key=<key>.

That call works on native routes since 2073282 (deprecated ?api_key= / ?Bugzilla_api_key= fallback in the native login), so the original change comes back unchanged. Last core resource of 2057358: only extension endpoints remain on the legacy REST server.

Changes

  • Revert of the revert ef9e9b0, i.e. the original 65642f5:
    • Add Bugzilla/API/V1/Bugzilla.pm (GET + OPTIONS on the 5 paths, same responses as before)
    • Remove Bugzilla/WebService/Bugzilla.pm, Resources/Bugzilla.pm and the Bugzilla dispatch entry
  • WS_DISPATCH now only holds the extensions registered through the webservice hook; Bugzilla/WebService.pm POD updated accordingly.
  • qa/t/rest_legacy_credentials.t checks Bugzilla_login/Bugzilla_password on GET /rest/component-watching, still served by the legacy server, instead of /rest/version.
  • qa/t/rest_bugzilla.t: GET /rest/jobqueue_status?api_key=<key> returns 200.
  • general.md: the resources still on the legacy auth path are now only some extension endpoints.

Test plan

  • GET /rest/version, /rest/timezone anonymously: 200, same JSON as before
  • GET /rest/extensions, /rest/time, /rest/jobqueue_status anonymously: 401 login_required; with X-Bugzilla-API-Key: 200
  • GET /rest/jobqueue_status?api_key=<key>: 200
  • GET /rest/component-watching with Bugzilla_login/Bugzilla_password: 200, and an error with bad credentials

References

…ource

Reverts ef9e9b0: the native login accepts ?api_key= since bug 2073282, so /rest/jobqueue_status?api_key=<key>
works again (now tested). rest_legacy_credentials.t moves to /rest/component-watching, still legacy.
@Xzzz
Xzzz requested a review from dklawren November 12, 2026 18:45
sub extensions {
my ($self) = @_;
Bugzilla->usage_mode(USAGE_MODE_MOJO_REST);
my $user = $self->bugzilla->login(LOGIN_REQUIRED);

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the legacy server let anonymous callers hit /rest/extensions and /rest/time (only requirelogin forced auth), so LOGIN_REQUIRED here and in time now returns 401 for them, so either keep them anonymous like before or document the new auth requirement in docs/en/md/api/core/v1/bugzilla.md (and integration.md, which points integrators at /rest/time)

Personally I am leaning to requiring login for the /extensions and /time endpoint because 1) knowing the extensions installed in a Bugzilla system could give sensitive info if the repo is private and 2) /time needs to know the users timezone for some of the values. So let's just update the docs to reflect the new requirement.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, keeping login required.

Doc updated in 6781396: "This method requires an authenticated user" under both requests in bugzilla.md (same wording as Job Queue Status), and the /rest/time polling step in integration.md now says so too.

As the tests already check the 401 for anonymous callers of both endpoints (qa/t/rest_bugzilla.t:50,61), only the docs change.

@Xzzz
Xzzz requested a review from dklawren November 13, 2026 15:43

@dklawren dklawren left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM r=dkl

@dklawren
dklawren merged commit 485b44f into mozilla:master Nov 13, 2026
13 of 14 checks passed
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.

2 participants