[codex] OPE-208 reject reserved admin create-user data fields

[salasebas]

Summary

Fixes OPE-208 by closing the admin create-user custom-data validation gap for snake_case reserved/generated user fields.

Root Cause

/admin/create-user validated data against camelCase reserved field names, but AdminStore::create_user writes custom data keys directly into the snake_case create query after setting defaults. That allowed fields like email_verified and ban_reason to overwrite protected defaults.

Changes

• Reject snake_case protected fields in admin create-user custom data.
• Expand the admin parity regression to cover both camelCase and snake_case reserved names.
• Preserve arbitrary non-reserved custom data behavior.

Validation

• cargo fmt --all --check
• cargo clippy --workspace --all-targets --all-features -- -D warnings
• cargo nextest run -p rustauth-plugins --all-features (760 passed, 3 skipped)

Linear: OPE-208

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
rustauth-docs-site	Ignored		Jul 2, 2026 8:05am

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a7021e9a39

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Reject configured physical field aliases

When an app configures custom database column names for protected user fields (for example AdminOptions.schema.user_ban_reason_field = "admin_ban_reason", or core user field_names aliases), this hard-coded alias list still allows that physical name through data. Schema-aware adapters resolve both logical and physical field names, so the create query writes the default protected value and then the request-supplied physical key maps to the same column later, overwriting it; validate against the configured schema/physical aliases as well as these default names.

Useful? React with 👍 / 👎.