Skip to content

feat: add default password warnings for PostgreSQL and Redis in Helm chart NOTES.txt - #3620

Merged
akshaydeo merged 28 commits into
devfrom
05-20-chore_show_warning_if_using_default_password_for_postgres_and_redis
May 25, 2026
Merged

feat: add default password warnings for PostgreSQL and Redis in Helm chart NOTES.txt#3620
akshaydeo merged 28 commits into
devfrom
05-20-chore_show_warning_if_using_default_password_for_postgres_and_redis

Conversation

@BearTS

@BearTS BearTS commented May 20, 2026

Copy link
Copy Markdown
Contributor

Summary

Adds runtime warnings to the Bifrost Helm chart's NOTES.txt when default passwords are detected for PostgreSQL or Redis, alerting operators before they deploy to production with insecure credentials.

Changes

  • Added a warning message displayed post-install if PostgreSQL is still using the default password "bifrost_password", prompting users to set postgresql.auth.password to a strong value.
  • Added a warning message displayed post-install if Redis is still using the default password "redis_password", prompting users to set vectorStore.redis.auth.password to a strong value.

Type of change

  • Bug fix
  • Feature
  • Refactor
  • Documentation
  • Chore/CI

Affected areas

  • Core (Go)
  • Transports (HTTP)
  • Providers/Integrations
  • Plugins
  • UI (React)
  • Docs

How to test

Deploy the Helm chart with default values and verify the warnings appear in the install notes:

helm install bifrost ./helm-charts/bifrost
# Expected: warnings about default PostgreSQL and Redis passwords appear in NOTES output

helm install bifrost ./helm-charts/bifrost \
  --set postgresql.auth.password=myStrongPass \
  --set vectorStore.redis.auth.password=myStrongRedisPass
# Expected: no warnings appear in NOTES output

Breaking changes

  • Yes
  • No

Related issues

Security considerations

This change surfaces a security risk to operators who leave default credentials in place when deploying to production. It does not change any authentication logic but ensures users are explicitly warned about insecure default passwords for PostgreSQL and Redis.

Checklist

  • I read docs/contributing/README.md and followed the guidelines
  • 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

@coderabbitai

coderabbitai Bot commented May 20, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

Warning

Rate limit exceeded

@BearTS has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 18 minutes and 18 seconds before requesting another review.

You’ve run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 3a627970-48a4-4cb5-aa82-7e3b8791e994

📥 Commits

Reviewing files that changed from the base of the PR and between c7f8227 and 0a44550.

📒 Files selected for processing (1)
  • helm-charts/bifrost/templates/NOTES.txt
📝 Walkthrough

Walkthrough

The Helm chart NOTES template now includes conditional warning messages that alert operators when default credentials remain in the deployment configuration. PostgreSQL warnings trigger when PostgreSQL is enabled with the default password, and Redis warnings trigger when the vector store is configured with Redis auth enabled and default credentials.

Changes

Default Credential Warnings in Helm Chart Notes

Layer / File(s) Summary
Credential warning messages
helm-charts/bifrost/templates/NOTES.txt
Conditional Helm template blocks added to warn about default PostgreSQL (bifrost_password) and Redis (redis_password) credentials when those services are enabled with those specific default values.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

I’m a rabbit in charts with a cautious nose,
Sniffing defaults where danger grows,
I bleep and I thump, a gentle alarm,
So creds won’t be left with old charm,
Hop safe, deployers—secure those rows! 🐇

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The PR title clearly and specifically describes the main change: adding default password warnings for PostgreSQL and Redis in the Helm chart NOTES.txt file.
Description check ✅ Passed The PR description follows the template structure with all major sections completed: Summary, Changes, Type of change, Affected areas, How to test, Breaking changes, Security considerations, and Checklist. The description provides clear context and actionable test cases.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch 05-20-chore_show_warning_if_using_default_password_for_postgres_and_redis

Comment @coderabbitai help to get the list of available commands and usage tips.

@BearTS
BearTS force-pushed the 05-20-chore_don_t_render_the_pvc_if_weavite_persistent_is_disabled branch from 680e813 to 988cd9d Compare May 20, 2026 10:56
@BearTS
BearTS force-pushed the 05-20-chore_show_warning_if_using_default_password_for_postgres_and_redis branch from 8815e31 to 11715a3 Compare May 20, 2026 10:56
@BearTS BearTS changed the title chore: show warning if using default password for postgres and redis feat: add default password warnings for PostgreSQL and Redis in Helm chart NOTES.txt May 20, 2026
@BearTS
BearTS marked this pull request as ready for review May 20, 2026 10:59
@BearTS
BearTS requested a review from a team as a code owner May 20, 2026 10:59
@greptile-apps

greptile-apps Bot commented May 20, 2026

Copy link
Copy Markdown
Contributor

Confidence Score: 5/5

Safe to merge — the change is additive, only touches NOTES.txt display logic, and does not affect any runtime behavior or authentication.

Both warning conditions are narrowly scoped with accurate guards, the logic matches the values.yaml defaults, and no runtime code paths are touched.

No files require special attention.

Important Files Changed

Filename Overview
helm-charts/bifrost/templates/NOTES.txt Adds post-install warnings for default PostgreSQL and Redis passwords; both guards are correctly conditioned on in-cluster deployment and auth being enabled

Reviews (7): Last reviewed commit: "Update helm-charts/bifrost/templates/NOT..." | Re-trigger Greptile

Comment thread helm-charts/bifrost/templates/NOTES.txt Outdated
Comment thread helm-charts/bifrost/templates/NOTES.txt Outdated
@BearTS
BearTS force-pushed the 05-20-chore_don_t_render_the_pvc_if_weavite_persistent_is_disabled branch from 988cd9d to a6055e7 Compare May 20, 2026 11:45
@BearTS
BearTS force-pushed the 05-20-chore_show_warning_if_using_default_password_for_postgres_and_redis branch from 11715a3 to 44ca875 Compare May 20, 2026 11:45
coderabbitai[bot]
coderabbitai Bot previously approved these changes May 20, 2026
Comment thread helm-charts/bifrost/templates/NOTES.txt Outdated
@BearTS
BearTS force-pushed the 05-20-chore_show_warning_if_using_default_password_for_postgres_and_redis branch from 4faf3e1 to 08770b6 Compare May 20, 2026 12:04
@BearTS
BearTS force-pushed the 05-20-chore_don_t_render_the_pvc_if_weavite_persistent_is_disabled branch 2 times, most recently from 029741c to 98ec709 Compare May 20, 2026 17:50
@BearTS
BearTS force-pushed the 05-20-chore_show_warning_if_using_default_password_for_postgres_and_redis branch from 08770b6 to 1ae5ae6 Compare May 20, 2026 17:50
Madhuvod and others added 6 commits May 22, 2026 04:45
## Summary

Briefly explain the purpose of this PR and the problem it solves.

## Changes

- What was changed and why
- Any notable design decisions or trade-offs

## Type of change

- [ ] Bug fix
- [ ] Feature
- [ ] Refactor
- [ ] Documentation
- [ ] Chore/CI

## Affected areas

- [ ] Core (Go)
- [ ] Transports (HTTP)
- [ ] Providers/Integrations
- [ ] Plugins
- [ ] UI (React)
- [ ] Docs

## How to test

Describe the steps to validate this change. Include commands and expected outcomes.

```sh
# Core/Transports
go version
go test ./...

# UI
cd ui
pnpm i || npm i
pnpm test || npm test
pnpm build || npm run build
```

If adding new configs or environment variables, document them here.

## Screenshots/Recordings

If UI changes, add before/after screenshots or short clips.

## Breaking changes

- [ ] Yes
- [ ] No

If yes, describe impact and migration instructions.

## Related issues

Link related issues and discussions. Example: Closes #123

## Security considerations

Note any security implications (auth, secrets, PII, sandboxing, etc.).

## Checklist

- [ ] I read `docs/contributing/README.md` and followed the guidelines
- [ ] 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
## Summary

Removes the hardcoded `type: "custom"` field that was being set by default for Anthropic tools during conversion. It is an optional field based on Anthropic docs and with this, can also support Deepseek as custom provider

## Changes

- Removed the automatic assignment of `AnthropicToolTypeCustom` when initializing `AnthropicTool` in `convertBifrostToolToAnthropic`, allowing the tool type to be determined by subsequent logic rather than being overridden at construction time.

## Type of change

- [x] Bug fix
- [ ] Feature
- [ ] Refactor
- [ ] Documentation
- [ ] Chore/CI

## Affected areas

- [ ] Core (Go)
- [ ] Transports (HTTP)
- [x] Providers/Integrations
- [ ] Plugins
- [ ] UI (React)
- [ ] Docs

## How to test

Send a request to the Anthropic provider with tools that are not of the custom type and verify they are correctly passed through without being overridden to `type: "custom"`.

```sh
go test ./core/providers/anthropic/...
```

## Breaking changes

- [ ] Yes
- [x] No

## Related issues

## Security considerations

None.

## Checklist

- [ ] I read `docs/contributing/README.md` and followed the guidelines
- [ ] 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
## Summary

When performing keyless `ListModels` requests, provider implementations were passing an empty `schemas.Key{}`, which caused model filtering to behave incorrectly — returning no models instead of all available models. This fix ensures keyless requests use a wildcard whitelist so all models are returned as expected.

## Changes

- Replaced `schemas.Key{}` with `schemas.Key{Models: schemas.WhiteList{"*"}}` in the keyless `ListModels` path for Anthropic, Cohere, Gemini, HuggingFace, and OpenAI providers.
- The wildcard `"*"` entry signals that all models should be allowed through the whitelist filter, matching the intended behavior for keyless configurations.

## Type of change

- [x] Bug fix
- [ ] Feature
- [ ] Refactor
- [ ] Documentation
- [ ] Chore/CI

## Affected areas

- [ ] Core (Go)
- [ ] Transports (HTTP)
- [x] Providers/Integrations
- [ ] Plugins
- [ ] UI (React)
- [ ] Docs

## How to test

Call `ListModels` against a provider configured with `IsKeyLess: true` and verify that the response includes the full list of available models rather than an empty result.

```sh
go test ./...
```

## Breaking changes

- [ ] Yes
- [x] No

## Related issues

- Resolves #3607

## Security considerations

No security implications. The wildcard whitelist only affects model listing behavior in explicitly keyless provider configurations.

## Checklist

- [x] I read `docs/contributing/README.md` and followed the guidelines
- [x] I added/updated tests where appropriate
- [x] I updated documentation where needed
- [x] I verified builds succeed (Go and UI)
- [ ] I verified the CI pipeline passes locally if applicable
…ms (#3647)

## Summary

When navigating between sidebar pages that support time filtering, the selected time range (start/end time or period) is lost. This PR preserves the active time filter parameters when clicking sidebar sub-items, so users don't have to re-select their time range after switching between time-filter-enabled pages.

## Changes

- When navigating from one `TimeFilterPages` page to another via a sidebar sub-item, the current `start_time`, `end_time`, and `period` query parameters are carried over to the destination URL.
- If the current or destination page is not in `TimeFilterPages`, navigation behaves as before with no parameter forwarding.

## Type of change

- [x] Bug fix
- [ ] Feature
- [ ] Refactor
- [ ] Documentation
- [ ] Chore/CI

## Affected areas

- [ ] Core (Go)
- [ ] Transports (HTTP)
- [ ] Providers/Integrations
- [ ] Plugins
- [x] UI (React)
- [ ] Docs

## How to test

1. Navigate to a page that supports time filtering (e.g., a metrics or logs page).
2. Set a custom time range or period using the time filter.
3. Click a different sidebar sub-item that also supports time filtering.
4. Verify the time range is preserved in the URL and the view reflects the same time window.
5. Navigate to a sidebar sub-item that does **not** support time filtering and verify no time parameters are appended.

```sh
cd ui
pnpm i || npm i
pnpm test || npm test
pnpm build || npm run build
```

## Screenshots/Recordings

N/A

## Breaking changes

- [ ] Yes
- [x] No

## Related issues

## Security considerations

No security implications. Only query parameters already present in the current URL are forwarded.

## Checklist

- [ ] I read `docs/contributing/README.md` and followed the guidelines
- [ ] 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
…edirect (#3648)

## Summary

Auth status checking on the login route was previously handled inside the `LoginView` component using a Redux query, causing a flash of "Checking authentication..." UI within the already-rendered login page. This moves the auth check to a TanStack Router route loader so the redirect to `/workspace` happens before the login page renders, and the pending state is handled cleanly by a dedicated `PendingComponent`.

## Changes

- Moved the `is-auth-enabled` auth check from `LoginView` into the `/login` route loader. If auth is disabled or the user already has a valid token, the loader throws a redirect to `/workspace` before the component mounts.
- Removed `useIsAuthEnabledQuery`, the `isCheckingAuth` state, and the inline loading UI from `LoginView`, simplifying the component significantly.
- Added a `PendingComponent` to the `/login` route that displays the "Checking authentication..." screen while the loader is in flight, with `pendingMs: 0` to show it immediately.
- Added `providesTags: ["Sessions"]` to `useIsAuthEnabledQuery` and updated `login` to `invalidatesTags: ["Sessions"]` so session state is properly invalidated after login. Also added `"Sessions"` to the logout invalidation list.

## Type of change

- [x] Refactor

## Affected areas

- [x] UI (React)

## How to test

1. Navigate to `/login` while unauthenticated — the "Checking authentication..." pending screen should appear briefly, then the login form should render.
2. Navigate to `/login` while already authenticated (valid session cookie) — you should be immediately redirected to `/workspace` without seeing the login form.
3. Navigate to `/login` when auth is disabled — you should be redirected to `/workspace`.
4. Submit valid credentials on the login form — you should be redirected to `/workspace`.

```sh
cd ui
pnpm i || npm i
pnpm build || npm run build
```

## Breaking changes

- [ ] Yes
- [x] No

## Related issues  
#3546

## Security considerations

The auth check now uses `credentials: "include"` in a plain `fetch` call within the route loader, ensuring the session cookie is sent. If the fetch fails, the login page is shown as a safe fallback rather than silently redirecting.

## Checklist

- [ ] I read `docs/contributing/README.md` and followed the guidelines
- [ ] 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
## Summary

Briefly explain the purpose of this PR and the problem it solves.

## Changes

- What was changed and why
- Any notable design decisions or trade-offs

## Type of change

- [ ] Bug fix
- [ ] Feature
- [ ] Refactor
- [ ] Documentation
- [ ] Chore/CI

## Affected areas

- [ ] Core (Go)
- [ ] Transports (HTTP)
- [ ] Providers/Integrations
- [ ] Plugins
- [ ] UI (React)
- [ ] Docs

## How to test

Describe the steps to validate this change. Include commands and expected outcomes.

```sh
# Core/Transports
go version
go test ./...

# UI
cd ui
pnpm i || npm i
pnpm test || npm test
pnpm build || npm run build
```

If adding new configs or environment variables, document them here.

## Screenshots/Recordings

If UI changes, add before/after screenshots or short clips.

## Breaking changes

- [ ] Yes
- [ ] No

If yes, describe impact and migration instructions.

## Related issues

Link related issues and discussions. Example: Closes #123

## Security considerations

Note any security implications (auth, secrets, PII, sandboxing, etc.).

## Checklist

- [ ] I read `docs/contributing/README.md` and followed the guidelines
- [ ] 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
impoiler and others added 7 commits May 22, 2026 04:45
## Summary

Fixes an issue where toast notifications were unclickable when a modal was open. Radix UI's `react-remove-scroll` sets `pointer-events: none` on elements outside the modal, which inadvertently blocked interaction with Sonner toasts.

## Changes

- Added a CSS rule to force `pointer-events: auto` on `[data-sonner-toaster]`, ensuring toasts remain interactive even when a modal overlay is active.

## Type of change

- [x] Bug fix
- [ ] Feature
- [ ] Refactor
- [ ] Documentation
- [ ] Chore/CI

## Affected areas

- [ ] Core (Go)
- [ ] Transports (HTTP)
- [ ] Providers/Integrations
- [ ] Plugins
- [x] UI (React)
- [ ] Docs

## How to test

1. Open any modal dialog in the UI.
2. Trigger a toast notification while the modal is open.
3. Verify the toast is visible and can be clicked/dismissed without closing the modal first.

## Screenshots/Recordings

Before: Toasts displayed behind/blocked by modal overlay and could not be clicked.
After: Toasts remain fully interactive while a modal is open.

## Breaking changes

- [ ] Yes
- [x] No

## Related issues

## Security considerations

None.

## Checklist

- [ ] I read `docs/contributing/README.md` and followed the guidelines
- [ ] 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
…rule and virtual key sheets (#3675)

## Summary

Cleans up the routing rule sheet UI by removing icon decorations from action buttons and fixing layout issues where the form content doesn't grow to fill available space in both the routing rule and virtual key sheets.

## Changes

- Removed the `X` and `Save` icons from the Cancel and Save/Update buttons in the routing rule sheet, leaving text-only labels
- Added `grow` and `flex flex-col` classes to the routing rule sheet form and its inner container so the form expands to fill the sheet height correctly
- Added `grow` to the virtual key sheet's inner content div for consistent layout behavior
- Moved the `RbacOperation`, `RbacResource`, and `useRbac` import to be grouped with other non-local imports

## Type of change

- [ ] Bug fix
- [x] Feature
- [ ] Refactor
- [ ] Documentation
- [ ] Chore/CI

## Affected areas

- [ ] Core (Go)
- [ ] Transports (HTTP)
- [ ] Providers/Integrations
- [ ] Plugins
- [x] UI (React)
- [ ] Docs

## How to test

1. Open the routing rules sheet (create or edit a rule) and verify the form content fills the full height of the sheet without collapsing.
2. Confirm the Cancel and Save/Update buttons display text only, without icons.
3. Open the virtual key sheet and verify the form content similarly fills the available height.

```sh
cd ui
pnpm i || npm i
pnpm build || npm run build
```

## Screenshots/Recordings

Before/after screenshots showing the button label changes and corrected sheet layout are recommended.

## Breaking changes

- [ ] Yes
- [x] No

## Related issues

## Security considerations

None.

## Checklist

- [ ] I read `docs/contributing/README.md` and followed the guidelines
- [ ] 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
… and scrollable body (#3676)

## Summary

Fixes the Virtual Keys table layout so it fills the available viewport height and scrolls internally, rather than causing the entire page to scroll. The table header remains sticky at the top while the body scrolls, and the pinned action column z-indices are corrected to prevent overlap issues.

## Changes

- Converted the outer container to a flex column layout with `grow` and `overflow-hidden` so the table section expands to fill remaining space without overflowing the page.
- Added `shrink-0` to the header/toolbar rows so they don't compress when space is constrained.
- Made the table container use `min-h-0 grow overflow-hidden` and passed `containerClassName="h-full overflow-auto"` so scrolling is scoped to the table body.
- Made `TableHeader` sticky (`sticky top-0 z-20`) with a background so column headers remain visible during vertical scroll.
- Adjusted z-index on the pinned right-side `TableHead` to `z-30` (above the sticky header row) and the pinned `TableCell` to `z-20` to maintain correct stacking order.
- Reduced pagination text to `text-xs` for visual consistency.

## Type of change

- [ ] Bug fix
- [x] Feature
- [ ] Refactor
- [ ] Documentation
- [ ] Chore/CI

## Affected areas

- [ ] Core (Go)
- [ ] Transports (HTTP)
- [ ] Providers/Integrations
- [ ] Plugins
- [x] UI (React)
- [ ] Docs

## How to test

1. Navigate to the Virtual Keys page with enough keys to require scrolling.
2. Verify the page itself does not scroll — only the table body scrolls.
3. Verify the column headers remain visible (sticky) as you scroll down.
4. Verify the pinned actions column on the right does not disappear behind the sticky header.
5. Verify row hover states on the pinned actions cell render correctly.

```sh
cd ui
pnpm i || npm i
pnpm build || npm run build
```

## Screenshots/Recordings

Before/after screenshots showing the table scrolling within its container rather than the full page scrolling are recommended.

## Breaking changes

- [ ] Yes
- [x] No

## Related issues

## Security considerations

None.

## Checklist

- [ ] I read `docs/contributing/README.md` and followed the guidelines
- [ ] 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
## Summary

`idleTimeoutReader` had several correctness issues: the cleanup function could return before an in-flight timer callback finished closing the body stream, panics from the underlying reader during a timeout-triggered close were unhandled, a nil context caused a panic, and a closed connection returned `nil` instead of a meaningful error.

## Changes

- Added a `timerDone` channel and `timerDoneOnce`/`cleanupOnce` guards so that `cleanup()` blocks until any concurrently running timer callback has fully completed, preventing races between cleanup and the idle timeout close path.
- Added a `recover()` deferred in `Read()` that catches panics from the underlying reader (e.g. reads on a closed pipe after timeout) and converts them into `ErrStreamIdleTimeout` or `ErrStreamClosed` rather than crashing.
- Extracted `connectionClosed()` and `closedReadError()` helpers to centralise nil-context safety and consistent error selection logic.
- Changed the connection-closed early-return in `Read()` to return `ErrStreamClosed` instead of `(0, nil)`, giving callers a clear signal.
- Introduced `ErrStreamClosed` as a named sentinel error for streams closed by cancellation or cleanup before a read begins.
- Added four new tests covering: nil context safety, closed-context returning `ErrStreamClosed`, panic recovery after timeout, and cleanup blocking until the timer callback finishes.

## Type of change

- [x] Bug fix

## Affected areas

- [x] Core (Go)

## How to test

```sh
go test ./core/providers/utils/... -v -race
```

All four new tests should pass, including `TestIdleTimeoutReader_CleanupWaitsForRunningTimerCallback` which validates the synchronisation behaviour under the race detector.

## Breaking changes

- [ ] Yes
- [x] No

## Security considerations

None. The changes are scoped to internal stream lifecycle management with no impact on auth, secrets, or PII handling.

## Checklist

- [ ] I read `docs/contributing/README.md` and followed the guidelines
- [x] I added/updated tests where appropriate
- [ ] I updated documentation where needed
- [x] I verified builds succeed (Go and UI)
- [ ] I verified the CI pipeline passes locally if applicable
## Summary

MCP tool log entries were not being stamped with DAC (Data Access Control) governance ownership fields (`user_id`, `team_id`, `customer_id`, `business_unit_id`) from the request context. This meant MCP logs could not be attributed to the correct organizational entities for governance and auditing purposes.

## Changes

- Introduced `applyMCPGovernanceFieldsToEntry`, a helper that reads governance identity fields from the `BifrostContext` and stamps them onto an `MCPToolLog` entry.
- Called this helper in both `PreMCPHook` and `PostMCPHook` so that governance fields are applied regardless of whether the log entry originates from a normal pre/post flow or the post-hook fallback path (where no pending pre-hook entry exists).
- Added `assertMCPLogGovernanceFields` as a shared test helper to validate all four governance fields on a log entry.
- Extended `TestMCPHooksDeferDBWriteUntilPostHookBatch` to set governance context values and assert they are persisted correctly.
- Added `TestPostMCPHookFallbackStampsGovernanceFields` to verify that fallback-created MCP log entries (post-hook only, no prior pre-hook) also carry the correct governance fields.

## Type of change

- [ ] Bug fix
- [x] Feature
- [ ] Refactor
- [ ] Documentation
- [ ] Chore/CI

## Affected areas

- [ ] Core (Go)
- [ ] Transports (HTTP)
- [ ] Providers/Integrations
- [x] Plugins
- [ ] UI (React)
- [ ] Docs

## How to test

```sh
go test ./plugins/logging/... -run TestMCPHooksDeferDBWriteUntilPostHookBatch
go test ./plugins/logging/... -run TestPostMCPHookFallbackStampsGovernanceFields
go test ./plugins/logging/...
```

Both tests should pass. Verify that after a `PreMCPHook` or `PostMCPHook` call with governance context values set, the resulting `MCPToolLog` entry in the store has non-nil `UserID`, `TeamID`, `CustomerID`, and `BusinessUnitID` matching the values placed in the context.

## Screenshots/Recordings

N/A

## Breaking changes

- [ ] Yes
- [x] No

## Related issues

N/A

## Security considerations

Governance ownership fields (`user_id`, `team_id`, `customer_id`, `business_unit_id`) are sourced exclusively from the authenticated request context and are only written when non-empty, ensuring no unintended data leakage or field overwriting occurs.

## 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
@BearTS
BearTS force-pushed the 05-20-chore_show_warning_if_using_default_password_for_postgres_and_redis branch from 1ae5ae6 to c7f8227 Compare May 22, 2026 08:20
@BearTS
BearTS force-pushed the 05-20-chore_don_t_render_the_pvc_if_weavite_persistent_is_disabled branch from 98ec709 to 9c66f50 Compare May 22, 2026 08:20
@BearTS
BearTS force-pushed the 05-20-chore_don_t_render_the_pvc_if_weavite_persistent_is_disabled branch from 9c66f50 to ac9cbbd Compare May 22, 2026 09:41
@BearTS
BearTS force-pushed the 05-20-chore_show_warning_if_using_default_password_for_postgres_and_redis branch from c7f8227 to 0a44550 Compare May 22, 2026 09:41

akshaydeo commented May 25, 2026

Copy link
Copy Markdown
Contributor

Merge activity

  • May 25, 6:33 AM UTC: A user started a stack merge that includes this pull request via Graphite.
  • May 25, 6:37 AM UTC: @akshaydeo merged this pull request with Graphite.

@akshaydeo
akshaydeo changed the base branch from 05-20-chore_don_t_render_the_pvc_if_weavite_persistent_is_disabled to graphite-base/3620 May 25, 2026 06:36
@akshaydeo
akshaydeo changed the base branch from graphite-base/3620 to dev May 25, 2026 06:36
@akshaydeo
akshaydeo dismissed coderabbitai[bot]’s stale review May 25, 2026 06:36

The base branch was changed.

@akshaydeo
akshaydeo merged commit 8013f6c into dev May 25, 2026
8 checks passed
@akshaydeo
akshaydeo deleted the 05-20-chore_show_warning_if_using_default_password_for_postgres_and_redis branch May 25, 2026 06:37
akshaydeo pushed a commit that referenced this pull request May 25, 2026
…chart NOTES.txt (#3620)

## Summary

Adds runtime warnings to the Bifrost Helm chart's `NOTES.txt` when default passwords are detected for PostgreSQL or Redis, alerting operators before they deploy to production with insecure credentials.

## Changes

- Added a warning message displayed post-install if PostgreSQL is still using the default password `"bifrost_password"`, prompting users to set `postgresql.auth.password` to a strong value.
- Added a warning message displayed post-install if Redis is still using the default password `"redis_password"`, prompting users to set `vectorStore.redis.auth.password` to a strong value.

## Type of change

- [ ] Bug fix
- [ ] Feature
- [ ] Refactor
- [ ] Documentation
- [x] Chore/CI

## Affected areas

- [ ] Core (Go)
- [ ] Transports (HTTP)
- [ ] Providers/Integrations
- [ ] Plugins
- [ ] UI (React)
- [ ] Docs

## How to test

Deploy the Helm chart with default values and verify the warnings appear in the install notes:

```sh
helm install bifrost ./helm-charts/bifrost
# Expected: warnings about default PostgreSQL and Redis passwords appear in NOTES output

helm install bifrost ./helm-charts/bifrost \
  --set postgresql.auth.password=myStrongPass \
  --set vectorStore.redis.auth.password=myStrongRedisPass
# Expected: no warnings appear in NOTES output
```

## Breaking changes

- [ ] Yes
- [x] No

## Related issues

## Security considerations

This change surfaces a security risk to operators who leave default credentials in place when deploying to production. It does not change any authentication logic but ensures users are explicitly warned about insecure default passwords for PostgreSQL and Redis.

## Checklist

- [ ] I read `docs/contributing/README.md` and followed the guidelines
- [ ] 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
Vaibhav701161 pushed a commit that referenced this pull request May 26, 2026
…chart NOTES.txt (#3620)

## Summary

Adds runtime warnings to the Bifrost Helm chart's `NOTES.txt` when default passwords are detected for PostgreSQL or Redis, alerting operators before they deploy to production with insecure credentials.

## Changes

- Added a warning message displayed post-install if PostgreSQL is still using the default password `"bifrost_password"`, prompting users to set `postgresql.auth.password` to a strong value.
- Added a warning message displayed post-install if Redis is still using the default password `"redis_password"`, prompting users to set `vectorStore.redis.auth.password` to a strong value.

## Type of change

- [ ] Bug fix
- [ ] Feature
- [ ] Refactor
- [ ] Documentation
- [x] Chore/CI

## Affected areas

- [ ] Core (Go)
- [ ] Transports (HTTP)
- [ ] Providers/Integrations
- [ ] Plugins
- [ ] UI (React)
- [ ] Docs

## How to test

Deploy the Helm chart with default values and verify the warnings appear in the install notes:

```sh
helm install bifrost ./helm-charts/bifrost
# Expected: warnings about default PostgreSQL and Redis passwords appear in NOTES output

helm install bifrost ./helm-charts/bifrost \
  --set postgresql.auth.password=myStrongPass \
  --set vectorStore.redis.auth.password=myStrongRedisPass
# Expected: no warnings appear in NOTES output
```

## Breaking changes

- [ ] Yes
- [x] No

## Related issues

## Security considerations

This change surfaces a security risk to operators who leave default credentials in place when deploying to production. It does not change any authentication logic but ensures users are explicitly warned about insecure default passwords for PostgreSQL and Redis.

## Checklist

- [ ] I read `docs/contributing/README.md` and followed the guidelines
- [ ] 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
akshaydeo pushed a commit that referenced this pull request May 26, 2026
…chart NOTES.txt (#3620)

## Summary

Adds runtime warnings to the Bifrost Helm chart's `NOTES.txt` when default passwords are detected for PostgreSQL or Redis, alerting operators before they deploy to production with insecure credentials.

## Changes

- Added a warning message displayed post-install if PostgreSQL is still using the default password `"bifrost_password"`, prompting users to set `postgresql.auth.password` to a strong value.
- Added a warning message displayed post-install if Redis is still using the default password `"redis_password"`, prompting users to set `vectorStore.redis.auth.password` to a strong value.

## Type of change

- [ ] Bug fix
- [ ] Feature
- [ ] Refactor
- [ ] Documentation
- [x] Chore/CI

## Affected areas

- [ ] Core (Go)
- [ ] Transports (HTTP)
- [ ] Providers/Integrations
- [ ] Plugins
- [ ] UI (React)
- [ ] Docs

## How to test

Deploy the Helm chart with default values and verify the warnings appear in the install notes:

```sh
helm install bifrost ./helm-charts/bifrost
# Expected: warnings about default PostgreSQL and Redis passwords appear in NOTES output

helm install bifrost ./helm-charts/bifrost \
  --set postgresql.auth.password=myStrongPass \
  --set vectorStore.redis.auth.password=myStrongRedisPass
# Expected: no warnings appear in NOTES output
```

## Breaking changes

- [ ] Yes
- [x] No

## Related issues

## Security considerations

This change surfaces a security risk to operators who leave default credentials in place when deploying to production. It does not change any authentication logic but ensures users are explicitly warned about insecure default passwords for PostgreSQL and Redis.

## Checklist

- [ ] I read `docs/contributing/README.md` and followed the guidelines
- [ ] 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
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.

8 participants