Fix: Enforce bot-type check on generateToken endpoint

[aji-aju]

Summary

• Restores the bot-type guard on PUT /v1/users/generateToken/{id} that was accidentally removed in Fix#8577: Refactor part of the secrets manager implementation  #8617 (Nov 2022)
• Non-bot users now receive a 400 Bad Request instead of a valid JWT token
• Adds a test to verify the endpoint rejects non-bot users

Context

• Reported via Pylon (NBN Update welcome page condition #19308) — the endpoint allowed generating JWT tokens for regular users, enabling API-level impersonation
• Fixed on main via Add POST /api/v1/users/generateToken endpoint for simplified token generation #25052, but that PR includes a new endpoint, schema changes, and UI refactoring — not suitable for cherry-pick
• This is a minimal targeted fix: just the 3-line bot guard + test

Test plan

• put_generateToken_bot_user_200_ok — existing test, still passes
• put_generateToken_non_bot_user_400 — new test, verifies non-bot users are rejected
• Manual testing via Swagger — confirmed 400 for regular user, 200 for bot user

🤖 Generated with Claude Code

[github-actions]

Hi there 👋 Thanks for your contribution!

The OpenMetadata team will review the PR shortly! Once it has been labeled as safe to test, the CI workflows
will start executing and we'll be able to make sure everything is working as expected.

Let us know if you need any help!

[github-actions]

Hi there 👋 Thanks for your contribution!

The OpenMetadata team will review the PR shortly! Once it has been labeled as safe to test, the CI workflows
will start executing and we'll be able to make sure everything is working as expected.

Let us know if you need any help!

[gitar-bot]

Code Review 👍 Approved with suggestions 0 resolved / 1 findings

Adds bot-type validation to the generateToken endpoint to prevent unauthorized token generation. The implementation is sound, but the test expects BAD_REQUEST while passing OK status to TestUtils—consider aligning the expected status code with the actual validation behavior.

💡 Quality: Test passes OK to put() but expects BAD_REQUEST from response

📄 openmetadata-service/src/test/java/org/openmetadata/service/resources/teams/UserResourceTest.java:1517

The test passes OK (200) as the expected status to TestUtils.put(), but the endpoint actually returns 400. This works by accident: put() sees a non-success status, throws HttpResponseException, and assertResponseContains() catches it and checks for BAD_REQUEST. However, the OK parameter is misleading and doesn't match the actual expectation. Other error-path tests in this codebase typically pass the correct expected error status to avoid confusion.

Suggested fix

Replace `OK` with `BAD_REQUEST`:
            TestUtils.put(
                getResource(String.format("users/generateToken/%s", user.getId())),
                new GenerateTokenRequest().withJWTTokenExpiry(JWTTokenExpiry.Seven),
                BAD_REQUEST,
                ADMIN_AUTH_HEADERS),

🤖 Prompt for agents

Code Review: Adds bot-type validation to the generateToken endpoint to prevent unauthorized token generation. The implementation is sound, but the test expects BAD_REQUEST while passing OK status to TestUtils—consider aligning the expected status code with the actual validation behavior.

1. 💡 Quality: Test passes OK to put() but expects BAD_REQUEST from response
   Files: openmetadata-service/src/test/java/org/openmetadata/service/resources/teams/UserResourceTest.java:1517

   The test passes `OK` (200) as the expected status to `TestUtils.put()`, but the endpoint actually returns 400. This works by accident: `put()` sees a non-success status, throws `HttpResponseException`, and `assertResponseContains()` catches it and checks for `BAD_REQUEST`. However, the `OK` parameter is misleading and doesn't match the actual expectation. Other error-path tests in this codebase typically pass the correct expected error status to avoid confusion.

   Suggested fix:
   Replace `OK` with `BAD_REQUEST`:
               TestUtils.put(
                   getResource(String.format("users/generateToken/%s", user.getId())),
                   new GenerateTokenRequest().withJWTTokenExpiry(JWTTokenExpiry.Seven),
                   BAD_REQUEST,
                   ADMIN_AUTH_HEADERS),

Options

Display: compact → Showing less information.

Comment with these commands to change:

Compact

gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[gitar-bot]

💡 Quality: Test passes OK to put() but expects BAD_REQUEST from response

The test passes OK (200) as the expected status to TestUtils.put(), but the endpoint actually returns 400. This works by accident: put() sees a non-success status, throws HttpResponseException, and assertResponseContains() catches it and checks for BAD_REQUEST. However, the OK parameter is misleading and doesn't match the actual expectation. Other error-path tests in this codebase typically pass the correct expected error status to avoid confusion.

Suggested fix:

Replace `OK` with `BAD_REQUEST`:
            TestUtils.put(
                getResource(String.format("users/generateToken/%s", user.getId())),
                new GenerateTokenRequest().withJWTTokenExpiry(JWTTokenExpiry.Seven),
                BAD_REQUEST,
                ADMIN_AUTH_HEADERS),

_{Was this helpful? React with 👍 / 👎 | Reply gitar fix to apply this suggestion}