Skip to content

[duplicate-code] Duplicate Code Pattern: Auth Validation Logic (TOML vs JSON Stdin Paths) #3561

@github-actions

Description

@github-actions

🔍 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

  1. 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
  2. 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

  • Extract validateServerAuthConfig helper into internal/config/validation.go
  • Update LoadFromFile in config_core.go to call the shared helper
  • Verify validateStandardServerConfig uses the same helper
  • Run make test-all to verify no regressions
  • Ensure error messages are consistent between TOML and JSON stdin paths

Parent Issue

See parent analysis report: #3560
Related to #3560

Generated by Duplicate Code Detector · ● 1M ·

  • expires on Apr 18, 2026, 5:52 AM UTC

Metadata

Metadata

Assignees

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions