The supplied .env.example uses four Admin security variable names that ConfigureBaseSecurityOptions never reads. Operators who copy the template and tune those limits silently retain defaults instead of the requested security settings.
Evidence and reproduction
At source commit ee5ea8a022da6a8c3f4f8b79bc8bf67ba499d6ef, .env.example lists the following names (source); the configuration code reads different names (source):
| Template name |
Name actually consumed |
CONDUIT_ADMIN_RATE_LIMITING_MAX_REQUESTS |
CONDUIT_ADMIN_RATE_LIMIT_MAX_REQUESTS |
CONDUIT_ADMIN_RATE_LIMITING_WINDOW_SECONDS |
CONDUIT_ADMIN_RATE_LIMIT_WINDOW_SECONDS |
CONDUIT_ADMIN_FAILED_AUTH_MAX_ATTEMPTS |
CONDUIT_ADMIN_MAX_FAILED_AUTH_ATTEMPTS |
CONDUIT_ADMIN_FAILED_AUTH_BAN_DURATION_MINUTES |
CONDUIT_ADMIN_AUTH_BAN_DURATION_MINUTES |
A standalone .NET 10 probe linked the actual security option/configuration source files. It called ConfigureAdminSecurityOptions with an in-memory configuration containing the template names, set to request quota=7, window=13 seconds, failed-auth threshold=2, and ban=3 minutes. Both enablement settings were true. Resolving IOptions<AdminSecurityOptions> produced the unchanged defaults:
MaxRequests=100
WindowSeconds=60
MaxAttempts=5
BanDurationMinutes=30
The service-specific Admin security documentation already uses the consumed names, so it disagrees with the main setup template.
Expected change
Align the main template with the supported names and decide whether the previously published names require compatibility aliases. Add a regression that evaluates the template's security settings through the production configuration callback, using nondefault values so silent ignored keys are visible.
Found while fixing #1580. This Admin bootstrap naming mismatch is independent of the Gateway shadow-options defect. Exact-name searches of open and closed issues for RATE_LIMITING_MAX_REQUESTS and RATE_LIMITING_WINDOW_SECONDS, plus env.example/security, found no matching defect.
The supplied
.env.exampleuses four Admin security variable names thatConfigureBaseSecurityOptionsnever reads. Operators who copy the template and tune those limits silently retain defaults instead of the requested security settings.Evidence and reproduction
At source commit
ee5ea8a022da6a8c3f4f8b79bc8bf67ba499d6ef,.env.examplelists the following names (source); the configuration code reads different names (source):CONDUIT_ADMIN_RATE_LIMITING_MAX_REQUESTSCONDUIT_ADMIN_RATE_LIMIT_MAX_REQUESTSCONDUIT_ADMIN_RATE_LIMITING_WINDOW_SECONDSCONDUIT_ADMIN_RATE_LIMIT_WINDOW_SECONDSCONDUIT_ADMIN_FAILED_AUTH_MAX_ATTEMPTSCONDUIT_ADMIN_MAX_FAILED_AUTH_ATTEMPTSCONDUIT_ADMIN_FAILED_AUTH_BAN_DURATION_MINUTESCONDUIT_ADMIN_AUTH_BAN_DURATION_MINUTESA standalone .NET 10 probe linked the actual security option/configuration source files. It called
ConfigureAdminSecurityOptionswith an in-memory configuration containing the template names, set to request quota=7, window=13 seconds, failed-auth threshold=2, and ban=3 minutes. Both enablement settings were true. ResolvingIOptions<AdminSecurityOptions>produced the unchanged defaults:The service-specific Admin security documentation already uses the consumed names, so it disagrees with the main setup template.
Expected change
Align the main template with the supported names and decide whether the previously published names require compatibility aliases. Add a regression that evaluates the template's security settings through the production configuration callback, using nondefault values so silent ignored keys are visible.
Found while fixing #1580. This Admin bootstrap naming mismatch is independent of the Gateway shadow-options defect. Exact-name searches of open and closed issues for
RATE_LIMITING_MAX_REQUESTSandRATE_LIMITING_WINDOW_SECONDS, plus env.example/security, found no matching defect.