fix(iam): accept long custom secret keys

[cxymds]

Pull Request

Description

A custom Secret Key longer than 40 characters is rejected by user and access-key forms, despite being usable by existing server update paths. Remove that ceiling and share UTF-8 byte validation across user creation, user editing, both service-account creation forms, and self-service password changes. Accept values of at least 8 bytes and submit the original value; keep generated service-account secrets at 40 characters.

Remove native character-count constraints from the affected secret inputs, translate the byte-based validation text in all 14 locales, and add boundary/Unicode regression tests. Backend creation support is in rustfs/rustfs#8419.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Code refactoring
• Performance improvement
• Test improvements
• Security fix

Testing

Tested tree: 5b1d6925e8c43e2b29965b188f71d2543b9e2079, with no additional source changes.

• Unit tests added/updated
• Manual testing completed

pnpm install --frozen-lockfile, pnpm type-check, pnpm lint, pnpm format:check, pnpm test:run, and git diff --check passed with Node.js 22.22.0. All 642 tests passed; new cases cover 40, 41, 90, 128, 256, 257, and 4096-byte values, the 8-byte minimum, and unchanged whitespace/Unicode semantics.

Manual checks used the actual local Next.js pages against a loopback mock API, with disposable fixtures and no real credential changes. The original access-key form rejects a 90-byte value; the updated form submits it intact. Mock request metadata confirms the full 90-byte fixture for both user creation and service-account creation. The updated form rejects ééé (6 bytes) and accepts éééé (8 bytes), including at a 390×720 CSS-pixel viewport. Short-secret errors and successful creation states were visually reviewed by a second reviewer.

Real RustFS authentication, S3 SigV4, storage persistence, and mixed-version deployments were not exercised by these UI checks. The backend PR records its separate verification. A pre-existing avatar aspect-ratio warning and transient failed fetches during the local mock restart were observed; subsequent fixture submissions succeeded.

pnpm test:run

Checklist

• Code follows the project's style guidelines
• Self-review completed
• TypeScript types are properly defined
• All commit messages are in English (Conventional Commits)
• All existing tests pass
• No new dependencies added, or they are justified

Related Issues

Refs rustfs/rustfs#8391.

Screenshots (if applicable)

Real local Console pages with a loopback mock API; all displayed credentials are disposable fixtures. The desktop pair compares validation behavior, not pixel-level layout changes.

Before: 90-byte secret rejected	After: 90-byte secret accepted

390×720 viewport: UTF-8 byte minimum

6-byte secret rejected	8-byte secret accepted

Additional Notes

Deploy with rustfs/rustfs#8419 to create service accounts with secrets longer than 40 bytes. Older servers can still reject creation even when existing update paths allow longer values. There is no new 256-byte cap, truncation, prehashing, Unicode normalization, generation-length change, or change to authentication and authorization.

Two independent reviewers covered correctness, security, compatibility, performance, simplicity, test coverage, and Console UX: no blocking findings within the stated unit/mock scope. Their review explicitly distinguished mock Store/UI checks from real process restarts and S3 authentication.