fix: support '/' in secret keys and updated docker to install bash

[AdeshGhadage]

Context

Fix #5598 handling of secret keys containing /.

Previously keys liketest/credproduced requests such as:

POST /api/v4/secrets/test/cred

which caused a 404 because/was interpreted as a URL path separator.

This PR introduces a helper that splits keys containing / into a folder path and the actual key name, appending the folder part to secretPath before sending the request.

Example:

test/cred → secretPath: /test, secretKey: cred

but One issue still remains: if the folder does not already exist, it will not be created and an error is shown saying the folder does not exist.

This PR also includes a Docker fix. Since node:20.20.0-trixie-slim does not include bash by default, local development was failing. I added bash installation in the Dockerfile to resolve this.

Screenshots

Steps to verify the change

Mentioned in the issue.

Type

• Fix
• Feature
• Improvement
• Breaking
• Docs
• Chore

Checklist

• Title follows the conventional commit format: type(scope): short description (scope is optional, e.g., fix: prevent crash on sync or fix(api): handle null response).
• Tested locally
• Updated docs (if needed)
• Read the contributing guide

[maidul98]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[greptile-apps]

Greptile Summary

This PR introduces a splitKeyAndPath helper in the frontend mutations layer to route keys containing / to the correct folder path and key name, fixing a 404 issue where / was being interpreted as a URL path separator. It also installs bash in Dockerfile.dev.fips to unblock local development.

Critical issues identified:

1. Cache invalidation bug (all three mutations): The onSuccess callbacks use the original secretPath from the caller, not the computed actualSecretPath. After a mutation, cache is invalidated for the wrong path, leaving the UI with stale data until manual refresh.

2. Double-slash paths: When a key starts with /, the path joining logic produces double slashes (e.g., //test or /some//test), which will cause routing errors.

3. Empty key edge case: Keys ending with / produce empty key segments in the URL, routing to unintended endpoints.

4. Incomplete fix: The standalone createSecret export is not updated and still contains the original bug for any callers using it directly.

5. Dockerfile optimization: The bash install duplicates the apt-get update call and introduces a redundant layer. Both installs should be merged.

The core routing approach is conceptually sound, but implementation issues prevent safe merging.

Confidence Score: 2/5

• Not safe to merge — multiple functional bugs in key path handling will cause cache invalidation failures and malformed URLs for certain inputs.
• The cache invalidation bug affects all three mutations and is critical for user experience. Combined with path normalization issues (double slashes for keys starting with /, empty segments for keys ending with /) and the uncovered standalone export, these implementation issues prevent safe merging. The Dockerfile change is correct but could be improved.
• frontend/src/hooks/api/secrets/mutations.tsx — All three hooks and the standalone export need fixes to handle edge cases and properly propagate the computed path to cache invalidation.

Comments Outside Diff (2)

1. frontend/src/hooks/api/secrets/mutations.tsx, line 468-470 (link)

   Standalone createSecret export not updated

   The standalone createSecret function at line 468 directly constructs the request URL from dto.secretKey without applying the splitKeyAndPath helper. Any caller using this function (rather than useCreateSecretV3) will still produce broken requests like POST /api/v4/secrets/test/cred when the key contains a /.

   This function should be updated to apply the same path-splitting logic used in the three hook mutations so the fix is applied consistently across all code paths.

2. frontend/src/hooks/api/secrets/mutations.tsx, line 72 (link)

   Cache invalidation receives original path parameter from caller

   The onSuccess callbacks in all three mutations (useCreateSecretV3 at line 72, useUpdateSecretV3 at line 146, and useDeleteSecretV3 at line 200) destructure secretPath from the original mutation call arguments. React Query always passes the original call variables to onSuccess, not locally reassigned values from mutationFn.

   Concrete scenario: If a user creates an entry with key = "test/cred" at path = "/":

   • The entry is stored at path /test ✓
   • But cache is invalidated using the original path "/" ✗

   This leaves the UI showing stale data — the created entry won't be visible until a manual refresh.

   To fix this across all three mutations, have mutationFn return the computed path alongside the API response, then use that returned value in onSuccess for all cache invalidation calls.

_{Last reviewed commit: d546319}

[greptile-apps]

Empty secret key when input ends with /

If a user enters a key with a trailing slash (e.g., "test/" or "/"), parts.pop() will return an empty string, making actualSecretKey = "". The resulting request URL becomes /api/v4/secrets/ (empty key segment), which hits an unintended endpoint or returns a confusing error.

Consider adding validation to guard against this case — either fall back to the original value so the server can return a proper validation error, or surface a clear client-side message before making the request.

[greptile-apps]

Double slash when key starts with leading forward slash

If the input key begins with / (e.g., "/test/cred"), the function produces paths with double slashes:

For example, with key = "/test/cred" and path = "/":

1. Split produces: ["", "test", "cred"]
2. After pop: parts = ["", "test"], so folderPart = "/test"
3. Result: actualPath = /${folderPart}=//test`

When path = "/some":

actualPath = "/some//test"  // double slash

These malformed paths will likely cause 404 errors or routing issues. Consider normalizing slashes:

Suggested change

	const splitKeyAndPath = (secretKey: string, secretPath: string = "/") => {
	if (!secretKey.includes("/")) {
	return { actualSecretKey: secretKey, actualSecretPath: secretPath };
	}
	const parts = secretKey.split("/");
	const actualSecretKey = parts.pop() as string;
	const folderPart = parts.join("/");
	const actualSecretPath =
	secretPath === "/"
	? `/${folderPart}`
	: `${secretPath}/${folderPart}`;
	return { actualSecretKey, actualSecretPath };
	};
	const actualSecretPath =
	secretPath === "/"
	? `/${folderPart}`.replace(/\/+/g, "/")
	: `${secretPath}/${folderPart}`.replace(/\/+/g, "/");