Skip to content

Validate provider configuration fields and surface friendly errors #10

Description

@deepintai

Context

The provider configuration handler already validates security header allowlists via validateHeaderFilterConfig() and converts errors to user-facing text via the friendlyError() helper. Other provider config fields (API key, base URL, timeout) are not validated, so user mistakes are caught late or produce confusing errors. Extending the same pattern catches errors early and keeps messages consistent.

What to do

  1. Review the provider config schema in deepintshield_server/core/schemas/ to identify validatable fields:
    • API key: must be non-empty and a reasonable length.
    • Base URL: must be a valid HTTP(S) URL when provided.
    • Timeout: must be a positive value.
  2. Add small validation functions in handlers/config.go for these field types (mirroring validateHeaderFilterConfig).
  3. Call them in the provider-config create/update handler and return HTTP 400 with messages produced via friendlyError() (e.g. "API key is required", "Base URL must be a valid http(s) URL").
  4. Preserve existing valid-config behavior.

Acceptance criteria

  • Validation added for at least 3 provider-config fields.
  • Invalid input rejected with HTTP 400 and a message routed through friendlyError() (not a raw error).
  • 2-3 test cases verifying validation and the friendly messages.
  • No regressions: go test ./transports/deepintshield-http/... passes.

File pointers

  • Handler + existing validator: deepintshield_server/transports/deepintshield-http/handlers/config.go (validateHeaderFilterConfig:865)
  • Friendly-error helper: deepintshield_server/transports/deepintshield-http/handlers/errors_friendly.go:29 (friendlyError)
  • Provider config schema: deepintshield_server/core/schemas/ (provider config types)

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requesthelp wantedExtra attention is needed

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions