🔍 Duplicate Code Pattern: Auth Validation Logic (TOML vs JSON Stdin Paths)
Part of duplicate code analysis: #3560
Summary
The OIDC fail-fast validation added in commit f2e4e444 introduces an auth validation loop in LoadFromFile (TOML path) that closely mirrors the auth validation already present in validateStandardServerConfig (JSON stdin path). Both blocks check for auth != nil, reject auth on non-HTTP servers with the same message, and call validateAuthConfig. The logic is duplicated across two different struct types (*ServerConfig for TOML and *StdinServerConfig for JSON stdin).
Duplication Details
Pattern: Inline auth type check + validateAuthConfig call
- Severity: Medium
- Occurrences: 2 locations
- Locations:
internal/config/config_core.go (lines 351–362) — TOML path, LoadFromFile
internal/config/validation.go (lines 218–240) — JSON stdin path, validateStandardServerConfig
config_core.go (TOML path):
for name, serverCfg := range cfg.Servers {
if serverCfg.Auth != nil {
// Auth is only supported on HTTP servers, matching validateStandardServerConfig behavior.
if serverCfg.Type != "http" {
return nil, fmt.Errorf("server '%s': auth is only supported for HTTP servers (type: \"http\")", name)
}
jsonPath := fmt.Sprintf("servers.%s", name)
if err := validateAuthConfig(serverCfg.Auth, name, jsonPath); err != nil {
return nil, err
}
}
}
validation.go (JSON stdin path, inside validateStandardServerConfig):
// auth is only valid on HTTP servers
if server.Auth != nil {
logValidateServerFailed(name, "auth field is not supported for stdio servers")
return rules.UnsupportedField("auth", "auth is only supported for HTTP servers (type: \"http\")", jsonPath, "Remove the 'auth' field from the stdio server configuration, or change the server type to 'http'")
}
// ...
if server.Type == "http" {
// ...
if server.Auth != nil {
if err := validateAuthConfig(server.Auth, name, jsonPath); err != nil {
return err
}
}
}
Key difference: The error messages diverge slightly — config_core.go uses fmt.Errorf while validation.go uses rules.UnsupportedField. This means the structured error format differs between config paths, which can confuse users depending on how they configure the gateway.
Impact Analysis
- Maintainability: Adding a new auth type or changing auth validation rules requires updates in both
config_core.go and validation.go. This has already happened once (this commit) and will happen again with future auth features.
- Bug Risk: Error message format divergence — users on the TOML path get plain
fmt.Errorf errors while JSON stdin users get structured rules.UnsupportedField errors. Inconsistent UX.
- Code Bloat: ~12 duplicated lines.
Refactoring Recommendations
-
Extract validateServerAuthConfig(name string, serverType string, auth *AuthConfig, jsonPath string) error
- Place in:
internal/config/validation.go (alongside validateAuthConfig)
- This shared helper performs the
auth != nil check, the type != "http" guard (returning a consistent rules.UnsupportedField error), and delegates to validateAuthConfig
- Both
LoadFromFile and validateStandardServerConfig call this shared helper
- Estimated effort: 1–2 hours
- Benefits: Single source of truth for auth validation, consistent error format across config paths
-
Normalize error format
- Update
config_core.go to use rules.UnsupportedField instead of fmt.Errorf for the non-HTTP auth error, matching the JSON stdin path behavior
Implementation Checklist
Parent Issue
See parent analysis report: #3560
Related to #3560
Generated by Duplicate Code Detector · ● 1M · ◷
🔍 Duplicate Code Pattern: Auth Validation Logic (TOML vs JSON Stdin Paths)
Part of duplicate code analysis: #3560
Summary
The OIDC fail-fast validation added in commit
f2e4e444introduces an auth validation loop inLoadFromFile(TOML path) that closely mirrors the auth validation already present invalidateStandardServerConfig(JSON stdin path). Both blocks check forauth != nil, reject auth on non-HTTP servers with the same message, and callvalidateAuthConfig. The logic is duplicated across two different struct types (*ServerConfigfor TOML and*StdinServerConfigfor JSON stdin).Duplication Details
Pattern: Inline auth type check +
validateAuthConfigcallinternal/config/config_core.go(lines 351–362) — TOML path,LoadFromFileinternal/config/validation.go(lines 218–240) — JSON stdin path,validateStandardServerConfigconfig_core.go(TOML path):validation.go(JSON stdin path, insidevalidateStandardServerConfig):Key difference: The error messages diverge slightly —
config_core.gousesfmt.Errorfwhilevalidation.gousesrules.UnsupportedField. This means the structured error format differs between config paths, which can confuse users depending on how they configure the gateway.Impact Analysis
config_core.goandvalidation.go. This has already happened once (this commit) and will happen again with future auth features.fmt.Errorferrors while JSON stdin users get structuredrules.UnsupportedFielderrors. Inconsistent UX.Refactoring Recommendations
Extract
validateServerAuthConfig(name string, serverType string, auth *AuthConfig, jsonPath string) errorinternal/config/validation.go(alongsidevalidateAuthConfig)auth != nilcheck, thetype != "http"guard (returning a consistentrules.UnsupportedFielderror), and delegates tovalidateAuthConfigLoadFromFileandvalidateStandardServerConfigcall this shared helperNormalize error format
config_core.goto userules.UnsupportedFieldinstead offmt.Errorffor the non-HTTP auth error, matching the JSON stdin path behaviorImplementation Checklist
validateServerAuthConfighelper intointernal/config/validation.goLoadFromFileinconfig_core.goto call the shared helpervalidateStandardServerConfiguses the same helpermake test-allto verify no regressionsParent Issue
See parent analysis report: #3560
Related to #3560