chore: add harness test for auth enabled - #3728
Merged
Merged
Conversation
17 tasks
Contributor
📝 WalkthroughSummary by CodeRabbit
WalkthroughThe Postman E2E collection is updated to test temporary token authentication configuration. The response contract for the auth check endpoint now requires ChangesTemp Token Auth E2E Tests
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
|
Contributor
Author
This stack of pull requests is managed by Graphite. Learn more about stacking. |
roroghost17
marked this pull request as ready for review
May 25, 2026 11:25
Contributor
Confidence Score: 3/5Safe to merge on an isolated CI instance, but will leave The only changed file is a Postman collection, so no production code is affected. The functional concern is that the PUT to enable tests/e2e/api/collections/bifrost-api-management.postman_collection.json — the missing reset step after the temp-token-auth PUT. Important Files Changed
Reviews (1): Last reviewed commit: "chore: add harness test for auth enabled" | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
🧹 Nitpick comments (2)
tests/e2e/api/collections/bifrost-api-management.postman_collection.json (2)
2314-2321: ⚡ Quick winAssert
is_auth_enabledis a boolean explicitly.You already validate type for
has_valid_token; doing the same foris_auth_enabledtightens this contract test.Proposed diff
pm.expect(body).to.have.property('is_auth_enabled'); pm.expect(body).to.have.property('has_valid_token'); pm.expect(body).to.have.property('auth_type'); + pm.expect(body.is_auth_enabled, 'is_auth_enabled is boolean').to.be.a('boolean'); pm.expect(body.has_valid_token, 'has_valid_token is boolean').to.be.a('boolean');🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@tests/e2e/api/collections/bifrost-api-management.postman_collection.json` around lines 2314 - 2321, The contract test "is-auth-enabled exposes auth_type + has_valid_token contract" currently asserts types for has_valid_token and auth_type but not for is_auth_enabled; update the Postman test block (the pm.test with that name) to add an explicit type assertion for body.is_auth_enabled (e.g., pm.expect(body.is_auth_enabled, 'is_auth_enabled is boolean').to.be.a('boolean')) so is_auth_enabled is validated as a boolean alongside has_valid_token and auth_type.
444-535: ⚡ Quick winWire the new config requests into global response-shape checks.
These new request names skip the collection-level
successShapescontract gate, so only local assertions run. Add shape mappings for them to keep stack-wide contract coverage consistent.Proposed diff
'Get Config': ['auth_config', 'client_config', 'framework_config', 'is_db_connected', 'is_logs_connected'], 'Update Config': ['message', 'status'], + 'Get Config (Verify Temp Token Auth)': ['auth_config', 'client_config', 'framework_config', 'is_db_connected', 'is_logs_connected'], + 'Update Config (Enable Temp Token Auth)': ['message', 'status'],🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@tests/e2e/api/collections/bifrost-api-management.postman_collection.json` around lines 444 - 535, The two new Postman requests "Update Config (Enable Temp Token Auth)" and "Get Config (Verify Temp Token Auth)" bypass the collection-level successShapes contract; add mappings for these request names into the collection's successShapes response-shape map so they run the global shape checks. Locate the collection-level successShapes mapping (the JSON object that maps request names to shape IDs) and add entries for "Update Config (Enable Temp Token Auth)" pointing to the appropriate update-config success shape and "Get Config (Verify Temp Token Auth)" pointing to the config-get success shape (reuse existing config-related shape IDs used by other Config requests) so the global contract gate covers these requests.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@tests/e2e/api/collections/bifrost-api-management.postman_collection.json`:
- Around line 2314-2321: The contract test "is-auth-enabled exposes auth_type +
has_valid_token contract" currently asserts types for has_valid_token and
auth_type but not for is_auth_enabled; update the Postman test block (the
pm.test with that name) to add an explicit type assertion for
body.is_auth_enabled (e.g., pm.expect(body.is_auth_enabled, 'is_auth_enabled is
boolean').to.be.a('boolean')) so is_auth_enabled is validated as a boolean
alongside has_valid_token and auth_type.
- Around line 444-535: The two new Postman requests "Update Config (Enable Temp
Token Auth)" and "Get Config (Verify Temp Token Auth)" bypass the
collection-level successShapes contract; add mappings for these request names
into the collection's successShapes response-shape map so they run the global
shape checks. Locate the collection-level successShapes mapping (the JSON object
that maps request names to shape IDs) and add entries for "Update Config (Enable
Temp Token Auth)" pointing to the appropriate update-config success shape and
"Get Config (Verify Temp Token Auth)" pointing to the config-get success shape
(reuse existing config-related shape IDs used by other Config requests) so the
global contract gate covers these requests.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: f5f54466-cf9d-468d-a618-2bfdd755c881
📒 Files selected for processing (1)
tests/e2e/api/collections/bifrost-api-management.postman_collection.json
akshaydeo
previously approved these changes
May 25, 2026
Contributor
Merge activity
|
akshaydeo
changed the base branch from
05-23-fix_allows_for_toggling_non-auth_users_for_mcp_temp_tokens
to
graphite-base/3728
May 25, 2026 16:37
akshaydeo
dismissed stale reviews from coderabbitai[bot] and themself
May 25, 2026 16:37
The base branch was changed.
akshaydeo
approved these changes
May 25, 2026
akshaydeo
pushed a commit
that referenced
this pull request
May 26, 2026
## Summary Extends the `/api/is-auth-enabled` endpoint contract to expose `has_valid_token` and `auth_type` fields alongside the existing `is_auth_enabled` field, and adds E2E test coverage for the new `mcp_enable_temp_token_auth` config flag. ## Changes - Updated the `Check If Auth Enabled` response field assertion to include `has_valid_token` and `auth_type` in addition to `is_auth_enabled`. - Added a test script to the `is-auth-enabled` request that validates: - `has_valid_token` is a boolean - `auth_type` is one of `'none'`, `'password'`, or `'sso'` - When auth is disabled, `auth_type` is `'none'` and `has_valid_token` is `false` - When auth is enabled, `auth_type` is not `'none'` - Added two new Postman requests under the config section: - **Update Config (Enable Temp Token Auth)** — PUTs `mcp_enable_temp_token_auth: true` to `/api/config` - **Get Config (Verify Temp Token Auth)** — GETs `/api/config` and asserts `mcp_enable_temp_token_auth` round-trips as `true` ## Type of change - [ ] Bug fix - [x] Feature - [ ] Refactor - [ ] Documentation - [ ] Chore/CI ## Affected areas - [ ] Core (Go) - [x] Transports (HTTP) - [ ] Providers/Integrations - [ ] Plugins - [ ] UI (React) - [ ] Docs ## How to test Run the updated Postman collection against a running Bifrost instance: ```sh newman run tests/e2e/api/collections/bifrost-api-management.postman_collection.json \ --env-var base_url=http://localhost:<port> ``` Expected outcomes: - `Check If Auth Enabled` response includes `is_auth_enabled`, `has_valid_token`, and `auth_type` - `auth_type` is one of `none`, `password`, or `sso` - `mcp_enable_temp_token_auth` can be set to `true` via PUT and is returned as `true` on subsequent GET ## Breaking changes - [ ] Yes - [x] No ## Related issues ## Security considerations The `has_valid_token` and `auth_type` fields are exposed on the `is-auth-enabled` endpoint. This endpoint is intended to be publicly accessible for client bootstrapping. Care should be taken to ensure no sensitive session or token details are leaked beyond the boolean and enum values validated here. ## Checklist - [ ] I read `docs/contributing/README.md` and followed the guidelines - [x] I added/updated tests where appropriate - [ ] I updated documentation where needed - [ ] I verified builds succeed (Go and UI) - [ ] I verified the CI pipeline passes locally if applicable
18 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Extends the
/api/is-auth-enabledendpoint contract to exposehas_valid_tokenandauth_typefields alongside the existingis_auth_enabledfield, and adds E2E test coverage for the newmcp_enable_temp_token_authconfig flag.Changes
Check If Auth Enabledresponse field assertion to includehas_valid_tokenandauth_typein addition tois_auth_enabled.is-auth-enabledrequest that validates:has_valid_tokenis a booleanauth_typeis one of'none','password', or'sso'auth_typeis'none'andhas_valid_tokenisfalseauth_typeis not'none'mcp_enable_temp_token_auth: trueto/api/config/api/configand assertsmcp_enable_temp_token_authround-trips astrueType of change
Affected areas
How to test
Run the updated Postman collection against a running Bifrost instance:
Expected outcomes:
Check If Auth Enabledresponse includesis_auth_enabled,has_valid_token, andauth_typeauth_typeis one ofnone,password, orssomcp_enable_temp_token_authcan be set totruevia PUT and is returned astrueon subsequent GETBreaking changes
Related issues
Security considerations
The
has_valid_tokenandauth_typefields are exposed on theis-auth-enabledendpoint. This endpoint is intended to be publicly accessible for client bootstrapping. Care should be taken to ensure no sensitive session or token details are leaked beyond the boolean and enum values validated here.Checklist
docs/contributing/README.mdand followed the guidelines