@mochabug/adaptkit/bin/genproto/mochabugapis/adapt/plugins/v1/http_proxy_service_pb.d.ts

A cmd to create, emulate and publish Mochabug Adapt plugins

import type { GenEnum, GenFile, GenMessage } from "@bufbuild/protobuf/codegenv2";
import type { Message } from "@bufbuild/protobuf";
/**
 * Describes the file mochabugapis/adapt/plugins/v1/http_proxy_service.proto.
 */
export declare const file_mochabugapis_adapt_plugins_v1_http_proxy_service: GenFile;
/**
 * The http proxy service definition
 *
 * This service provides HTTP proxy capabilities with optional TLS configuration
 * and dynamic header injection for outgoing requests.
 *
 * An HTTP proxy configuration must do at least one of the following:
 * - Configure custom TLS settings (self-signed certs, mTLS, CA pinning)
 * - Inject dynamic headers using template variables
 *
 * If neither TLS nor header injection is configured, the proxy provides no value
 * and the plugin should use direct HTTP requests instead.
 *
 * Example use cases:
 * - Adding authentication headers to upstream services (Bearer tokens, API keys)
 * - Injecting custom correlation IDs or tracking headers
 * - Using mutual TLS (mTLS) for B2B API authentication
 * - Connecting to services with self-signed certificates
 *
 * @generated from message mochabugapis.adapt.plugins.v1.HttpProxyDefinition
 */
export type HttpProxyDefinition = Message<"mochabugapis.adapt.plugins.v1.HttpProxyDefinition"> & {
    /**
     * REQUIRED: Allowed upstream hosts that this proxy can connect to.
     *
     * Plugin authors define which external services the plugin will communicate with.
     * Only publicly accessible hosts are allowed; private IP addresses and non-globally
     * resolvable hostnames are blocked by the platform.
     *
     * ## Transparency & User Visibility
     *
     * IMPORTANT: This list is VISIBLE to users during plugin installation and in plugin settings.
     * Users can see exactly which external endpoints your plugin will connect to.
     *
     * Plugin authors MUST be transparent about:
     * - Which services the plugin connects to
     * - Why the plugin needs to connect to these hosts
     * - What data is sent to these endpoints
     *
     * Plugins that attempt to hide their network activity or connect to undisclosed endpoints
     * will be flagged as malicious and removed from the plugin marketplace.
     *
     * ## Format
     *
     * Each entry must be a valid hostname or publicly routable IP address, optionally with a port:
     * - "api.example.com" - Exact hostname match
     * - "*.example.com" - Wildcard subdomain match (matches api.example.com, service.example.com, etc.)
     * - "api.example.com:8443" - Hostname with specific port
     * - "*.example.com:8443" - Wildcard subdomain with specific port
     *
     * ## Wildcard Rules
     *
     * - "*" at the start means "any subdomain at any depth" but NOT the root domain
     *   - "*.example.com" matches "api.example.com", "a.b.example.com", etc.
     *   - "*.example.com" does NOT match "example.com"
     *   - To allow both, add both entries: ["*.example.com", "example.com"]
     *
     * - Wildcards only supported at the subdomain level
     *   - Valid: "*.example.com", "*.api.example.com"
     *   - Invalid: "api.*.com", "*", "example.*"
     *
     * ## Port Matching
     *
     * - If no port specified: matches any port on that host
     *   - "api.example.com" matches api.example.com:80, api.example.com:443, api.example.com:8080
     *
     * - If port specified: matches only that specific port
     *   - "api.example.com:443" matches ONLY api.example.com:443
     *   - Does NOT match api.example.com:80 or api.example.com:8443
     *
     * ## Restrictions
     *
     * The following are blocked and will cause validation errors:
     * - Private IP ranges (RFC 1918): 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
     * - Loopback addresses: 127.0.0.0/8, ::1
     * - Link-local addresses: 169.254.0.0/16, fe80::/10
     * - Non-globally resolvable hostnames: localhost, *.local, *.internal
     *
     * ## Examples
     *
     * 1. Single API endpoint:
     *    allowed_hosts: ["api.example.com"]
     *
     * 2. Multiple environments:
     *    allowed_hosts: ["api.prod.example.com", "api.staging.example.com"]
     *
     * 3. All subdomains of a service:
     *    allowed_hosts: ["*.service.example.com", "service.example.com"]
     *
     * 4. Specific port (e.g., non-standard HTTPS):
     *    allowed_hosts: ["api.example.com:8443"]
     *
     * @generated from field: repeated string allowed_hosts = 1;
     */
    allowedHosts: string[];
    /**
     * Optional TLS configuration for the upstream connection.
     *
     * If not specified:
     * - The protocol (HTTP/HTTPS) is forwarded from the incoming request
     * - HTTP requests are proxied as HTTP
     * - HTTPS requests are proxied as HTTPS using the system's default trust store
     *   (publicly trusted Certificate Authorities like Let's Encrypt, DigiCert, etc.)
     *
     * If specified:
     * - For MODE_SERVER_ONLY: Validates the server certificate against the provided ca_bundle
     * - For MODE_MTLS: Performs mutual TLS authentication with client certificate
     *
     * Use this when:
     * - Upstream uses self-signed certificates (provide custom ca_bundle)
     * - Upstream requires mutual TLS (provide client certificate and private key)
     * - Need to pin specific CA certificates for security
     *
     * @generated from field: optional mochabugapis.adapt.plugins.v1.TlsDefinition tls = 2;
     */
    tls?: TlsDefinition | undefined;
    /**
     * Dynamic headers to inject into every proxied request using template variables.
     *
     * This field is for headers that require DYNAMIC values resolved from template variables.
     * The caller can always submit static headers directly with each request - this field
     * is specifically for injecting headers that use variable substitution (e.g., %ACCESS_TOKEN%).
     *
     * ## When to Use inject_headers
     *
     * Use this field when you need to inject headers with:
     * - Values that change per request or per user (tokens, session IDs)
     * - Values that come from user configuration (API keys, tenant IDs)
     * - Values that need to be kept secret (credentials, tokens)
     * - Dynamic template substitution using %VARIABLE% syntax
     *
     * ## When NOT to Use inject_headers
     *
     * Do NOT use this field for:
     * - Static headers that never change (use direct headers in the request)
     * - Headers that the caller controls (they can submit these directly)
     * - Constant values like "Content-Type: application/json"
     *
     * The caller can always add, modify, or override headers in their individual requests.
     * This field is for headers that the plugin definition requires to be injected with
     * dynamic values before reaching the upstream service.
     *
     * ## Header Processing
     *
     * The map key is the HTTP header name (e.g., "Authorization", "X-Api-Key").
     * Header names are case-insensitive per RFC 7230 but will be sent as specified.
     *
     * If the same header name appears in both inject_headers and the caller's request:
     * - The inject_headers value takes precedence (overrides caller's value)
     * - This ensures plugin-level authentication/configuration is always applied
     *
     * ## Common Patterns
     *
     * - "Authorization": "Bearer %ACCESS_TOKEN%" - Dynamic OAuth2 token
     * - "X-Api-Key": "%API_KEY%" - User-provided API key
     * - "X-Request-ID": "%CORRELATION_ID%" - Tracing identifier
     * - "X-Tenant-ID": "%TENANT_ID%" - Multi-tenant identifier
     *
     * @generated from field: map<string, mochabugapis.adapt.plugins.v1.HeaderTemplate> inject_headers = 3;
     */
    injectHeaders: {
        [key: string]: HeaderTemplate;
    };
    /**
     * When true: the user defines which hosts this proxy connects to.
     *   - Definition's allowed_hosts become optional defaults shown in the UI.
     *   - User's hosts in the pluginservices HTTP proxy config REPLACE the entire list.
     *   - If user provides no hosts and definition has no defaults, the service is not configured.
     *
     * When false or unset (default): current behavior.
     *   - Definition's allowed_hosts are fixed and enforced.
     *   - User cannot override hosts in config.
     *
     * @generated from field: optional bool user_defined_hosts = 4;
     */
    userDefinedHosts?: boolean | undefined;
};
/**
 * The http proxy service definition
 *
 * This service provides HTTP proxy capabilities with optional TLS configuration
 * and dynamic header injection for outgoing requests.
 *
 * An HTTP proxy configuration must do at least one of the following:
 * - Configure custom TLS settings (self-signed certs, mTLS, CA pinning)
 * - Inject dynamic headers using template variables
 *
 * If neither TLS nor header injection is configured, the proxy provides no value
 * and the plugin should use direct HTTP requests instead.
 *
 * Example use cases:
 * - Adding authentication headers to upstream services (Bearer tokens, API keys)
 * - Injecting custom correlation IDs or tracking headers
 * - Using mutual TLS (mTLS) for B2B API authentication
 * - Connecting to services with self-signed certificates
 *
 * @generated from message mochabugapis.adapt.plugins.v1.HttpProxyDefinition
 */
export type HttpProxyDefinitionJson = {
    /**
     * REQUIRED: Allowed upstream hosts that this proxy can connect to.
     *
     * Plugin authors define which external services the plugin will communicate with.
     * Only publicly accessible hosts are allowed; private IP addresses and non-globally
     * resolvable hostnames are blocked by the platform.
     *
     * ## Transparency & User Visibility
     *
     * IMPORTANT: This list is VISIBLE to users during plugin installation and in plugin settings.
     * Users can see exactly which external endpoints your plugin will connect to.
     *
     * Plugin authors MUST be transparent about:
     * - Which services the plugin connects to
     * - Why the plugin needs to connect to these hosts
     * - What data is sent to these endpoints
     *
     * Plugins that attempt to hide their network activity or connect to undisclosed endpoints
     * will be flagged as malicious and removed from the plugin marketplace.
     *
     * ## Format
     *
     * Each entry must be a valid hostname or publicly routable IP address, optionally with a port:
     * - "api.example.com" - Exact hostname match
     * - "*.example.com" - Wildcard subdomain match (matches api.example.com, service.example.com, etc.)
     * - "api.example.com:8443" - Hostname with specific port
     * - "*.example.com:8443" - Wildcard subdomain with specific port
     *
     * ## Wildcard Rules
     *
     * - "*" at the start means "any subdomain at any depth" but NOT the root domain
     *   - "*.example.com" matches "api.example.com", "a.b.example.com", etc.
     *   - "*.example.com" does NOT match "example.com"
     *   - To allow both, add both entries: ["*.example.com", "example.com"]
     *
     * - Wildcards only supported at the subdomain level
     *   - Valid: "*.example.com", "*.api.example.com"
     *   - Invalid: "api.*.com", "*", "example.*"
     *
     * ## Port Matching
     *
     * - If no port specified: matches any port on that host
     *   - "api.example.com" matches api.example.com:80, api.example.com:443, api.example.com:8080
     *
     * - If port specified: matches only that specific port
     *   - "api.example.com:443" matches ONLY api.example.com:443
     *   - Does NOT match api.example.com:80 or api.example.com:8443
     *
     * ## Restrictions
     *
     * The following are blocked and will cause validation errors:
     * - Private IP ranges (RFC 1918): 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
     * - Loopback addresses: 127.0.0.0/8, ::1
     * - Link-local addresses: 169.254.0.0/16, fe80::/10
     * - Non-globally resolvable hostnames: localhost, *.local, *.internal
     *
     * ## Examples
     *
     * 1. Single API endpoint:
     *    allowed_hosts: ["api.example.com"]
     *
     * 2. Multiple environments:
     *    allowed_hosts: ["api.prod.example.com", "api.staging.example.com"]
     *
     * 3. All subdomains of a service:
     *    allowed_hosts: ["*.service.example.com", "service.example.com"]
     *
     * 4. Specific port (e.g., non-standard HTTPS):
     *    allowed_hosts: ["api.example.com:8443"]
     *
     * @generated from field: repeated string allowed_hosts = 1;
     */
    allowedHosts?: string[];
    /**
     * Optional TLS configuration for the upstream connection.
     *
     * If not specified:
     * - The protocol (HTTP/HTTPS) is forwarded from the incoming request
     * - HTTP requests are proxied as HTTP
     * - HTTPS requests are proxied as HTTPS using the system's default trust store
     *   (publicly trusted Certificate Authorities like Let's Encrypt, DigiCert, etc.)
     *
     * If specified:
     * - For MODE_SERVER_ONLY: Validates the server certificate against the provided ca_bundle
     * - For MODE_MTLS: Performs mutual TLS authentication with client certificate
     *
     * Use this when:
     * - Upstream uses self-signed certificates (provide custom ca_bundle)
     * - Upstream requires mutual TLS (provide client certificate and private key)
     * - Need to pin specific CA certificates for security
     *
     * @generated from field: optional mochabugapis.adapt.plugins.v1.TlsDefinition tls = 2;
     */
    tls?: TlsDefinitionJson;
    /**
     * Dynamic headers to inject into every proxied request using template variables.
     *
     * This field is for headers that require DYNAMIC values resolved from template variables.
     * The caller can always submit static headers directly with each request - this field
     * is specifically for injecting headers that use variable substitution (e.g., %ACCESS_TOKEN%).
     *
     * ## When to Use inject_headers
     *
     * Use this field when you need to inject headers with:
     * - Values that change per request or per user (tokens, session IDs)
     * - Values that come from user configuration (API keys, tenant IDs)
     * - Values that need to be kept secret (credentials, tokens)
     * - Dynamic template substitution using %VARIABLE% syntax
     *
     * ## When NOT to Use inject_headers
     *
     * Do NOT use this field for:
     * - Static headers that never change (use direct headers in the request)
     * - Headers that the caller controls (they can submit these directly)
     * - Constant values like "Content-Type: application/json"
     *
     * The caller can always add, modify, or override headers in their individual requests.
     * This field is for headers that the plugin definition requires to be injected with
     * dynamic values before reaching the upstream service.
     *
     * ## Header Processing
     *
     * The map key is the HTTP header name (e.g., "Authorization", "X-Api-Key").
     * Header names are case-insensitive per RFC 7230 but will be sent as specified.
     *
     * If the same header name appears in both inject_headers and the caller's request:
     * - The inject_headers value takes precedence (overrides caller's value)
     * - This ensures plugin-level authentication/configuration is always applied
     *
     * ## Common Patterns
     *
     * - "Authorization": "Bearer %ACCESS_TOKEN%" - Dynamic OAuth2 token
     * - "X-Api-Key": "%API_KEY%" - User-provided API key
     * - "X-Request-ID": "%CORRELATION_ID%" - Tracing identifier
     * - "X-Tenant-ID": "%TENANT_ID%" - Multi-tenant identifier
     *
     * @generated from field: map<string, mochabugapis.adapt.plugins.v1.HeaderTemplate> inject_headers = 3;
     */
    injectHeaders?: {
        [key: string]: HeaderTemplateJson;
    };
    /**
     * When true: the user defines which hosts this proxy connects to.
     *   - Definition's allowed_hosts become optional defaults shown in the UI.
     *   - User's hosts in the pluginservices HTTP proxy config REPLACE the entire list.
     *   - If user provides no hosts and definition has no defaults, the service is not configured.
     *
     * When false or unset (default): current behavior.
     *   - Definition's allowed_hosts are fixed and enforced.
     *   - User cannot override hosts in config.
     *
     * @generated from field: optional bool user_defined_hosts = 4;
     */
    userDefinedHosts?: boolean;
};
/**
 * Describes the message mochabugapis.adapt.plugins.v1.HttpProxyDefinition.
 * Use `create(HttpProxyDefinitionSchema)` to create a new message.
 */
export declare const HttpProxyDefinitionSchema: GenMessage<HttpProxyDefinition, {
    jsonType: HttpProxyDefinitionJson;
}>;
/**
 * HeaderTemplate defines a template string using Envoy-style %VAR% syntax
 * for dynamic header value substitution.
 *
 * ## Template Syntax
 *
 * Variables are enclosed in percent signs: %VARIABLE_NAME%
 *
 * Variable names must:
 * - Start with a letter or underscore
 * - Contain only letters, numbers, and underscores
 * - Be case-sensitive
 *
 * ## Examples
 *
 * 1. Bearer Token:
 *    template: "Bearer %ACCESS_TOKEN%"
 *    Result: "Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..."
 *
 * 2. API Key:
 *    template: "ApiKey %API_KEY%"
 *    Result: "ApiKey sk_live_51HqG8sKj..."
 *
 * 3. Multiple Variables:
 *    template: "%TENANT_ID%:%USER_ID%"
 *    Result: "org_123:user_456"
 *
 * 4. Mixed Static and Dynamic:
 *    template: "v1.0/%API_VERSION%/client/%CLIENT_ID%"
 *    Result: "v1.0/2024-01/client/client_abc123"
 *
 * ## Escaping Literal Percent Signs
 *
 * To include a literal percent sign (%) in the header value, double it:
 *
 * - template: "100%%" → Result: "100%"
 * - template: "Completion: 95%% done" → Result: "Completion: 95% done"
 * - template: "%%VAR%%" → Result: "%VAR%"
 *
 * ## Variable Resolution
 *
 * Template variables are provided by users when they configure or use the plugin.
 * For system services, plugin authors provide the variable values.
 *
 * The resolution process is transparent:
 * - Users see which hostname will receive the request (from allowed_hosts)
 * - Users see which header is being modified
 * - Users are prompted to provide values for each variable
 *
 * This ensures users know exactly what data they are sending and where it goes.
 *
 * If a variable is not provided, the header injection will fail at runtime,
 * and the proxy request will not be sent.
 *
 * ## Security Considerations
 *
 * By default, template variables are treated as SECRETS.
 *
 * Set `plaintext: true` if the variable contains non-sensitive data like:
 * - User IDs (not passwords)
 * - Tenant/Organization IDs
 * - Request correlation IDs
 * - API version numbers
 * - Public configuration values
 *
 * DO NOT set `plaintext: true` for:
 * - Access tokens, API keys, passwords
 * - Session tokens, JWTs
 * - Private keys, certificates
 * - Any credential material
 *
 * @generated from message mochabugapis.adapt.plugins.v1.HeaderTemplate
 */
export type HeaderTemplate = Message<"mochabugapis.adapt.plugins.v1.HeaderTemplate"> & {
    /**
     * The template string using %VAR% syntax.
     *
     * Pattern: %VARIABLE_NAME% where VARIABLE_NAME matches [A-Za-z_][A-Za-z0-9_]*
     * Escape literal %: use %%
     *
     * @generated from field: string template = 1;
     */
    template: string;
    /**
     * If true, variables in this template are NOT treated as secrets.
     *
     * Only set to true for non-sensitive identifiers like user IDs,
     * tenant IDs, request IDs, or public configuration values.
     *
     * Default: false (variables are secrets)
     *
     * @generated from field: bool plaintext = 2;
     */
    plaintext: boolean;
};
/**
 * HeaderTemplate defines a template string using Envoy-style %VAR% syntax
 * for dynamic header value substitution.
 *
 * ## Template Syntax
 *
 * Variables are enclosed in percent signs: %VARIABLE_NAME%
 *
 * Variable names must:
 * - Start with a letter or underscore
 * - Contain only letters, numbers, and underscores
 * - Be case-sensitive
 *
 * ## Examples
 *
 * 1. Bearer Token:
 *    template: "Bearer %ACCESS_TOKEN%"
 *    Result: "Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..."
 *
 * 2. API Key:
 *    template: "ApiKey %API_KEY%"
 *    Result: "ApiKey sk_live_51HqG8sKj..."
 *
 * 3. Multiple Variables:
 *    template: "%TENANT_ID%:%USER_ID%"
 *    Result: "org_123:user_456"
 *
 * 4. Mixed Static and Dynamic:
 *    template: "v1.0/%API_VERSION%/client/%CLIENT_ID%"
 *    Result: "v1.0/2024-01/client/client_abc123"
 *
 * ## Escaping Literal Percent Signs
 *
 * To include a literal percent sign (%) in the header value, double it:
 *
 * - template: "100%%" → Result: "100%"
 * - template: "Completion: 95%% done" → Result: "Completion: 95% done"
 * - template: "%%VAR%%" → Result: "%VAR%"
 *
 * ## Variable Resolution
 *
 * Template variables are provided by users when they configure or use the plugin.
 * For system services, plugin authors provide the variable values.
 *
 * The resolution process is transparent:
 * - Users see which hostname will receive the request (from allowed_hosts)
 * - Users see which header is being modified
 * - Users are prompted to provide values for each variable
 *
 * This ensures users know exactly what data they are sending and where it goes.
 *
 * If a variable is not provided, the header injection will fail at runtime,
 * and the proxy request will not be sent.
 *
 * ## Security Considerations
 *
 * By default, template variables are treated as SECRETS.
 *
 * Set `plaintext: true` if the variable contains non-sensitive data like:
 * - User IDs (not passwords)
 * - Tenant/Organization IDs
 * - Request correlation IDs
 * - API version numbers
 * - Public configuration values
 *
 * DO NOT set `plaintext: true` for:
 * - Access tokens, API keys, passwords
 * - Session tokens, JWTs
 * - Private keys, certificates
 * - Any credential material
 *
 * @generated from message mochabugapis.adapt.plugins.v1.HeaderTemplate
 */
export type HeaderTemplateJson = {
    /**
     * The template string using %VAR% syntax.
     *
     * Pattern: %VARIABLE_NAME% where VARIABLE_NAME matches [A-Za-z_][A-Za-z0-9_]*
     * Escape literal %: use %%
     *
     * @generated from field: string template = 1;
     */
    template?: string;
    /**
     * If true, variables in this template are NOT treated as secrets.
     *
     * Only set to true for non-sensitive identifiers like user IDs,
     * tenant IDs, request IDs, or public configuration values.
     *
     * Default: false (variables are secrets)
     *
     * @generated from field: bool plaintext = 2;
     */
    plaintext?: boolean;
};
/**
 * Describes the message mochabugapis.adapt.plugins.v1.HeaderTemplate.
 * Use `create(HeaderTemplateSchema)` to create a new message.
 */
export declare const HeaderTemplateSchema: GenMessage<HeaderTemplate, {
    jsonType: HeaderTemplateJson;
}>;
/**
 * TLS configuration defining the security requirements for upstream connections.
 *
 * Supports two authentication modes. CA bundles live in runtime config because
 * HTTP proxy settings use bindings to reference user-scoped certificate material.
 *
 * ## Security Model
 *
 * - CA bundles: MUST be in config
 * - Private keys and client certificates: MUST be in config
 *
 * ## Mode Descriptions
 *
 * MODE_SERVER_ONLY: Validate server's certificate (standard HTTPS)
 * - Client verifies server identity
 * - Server does not verify client
 * - Common for public APIs
 *
 * MODE_MTLS: Mutual authentication (both parties verify each other)
 * - Client verifies server identity AND presents its own certificate
 * - Server verifies client identity
 * - Common for B2B integrations, internal services
 *
 * @generated from message mochabugapis.adapt.plugins.v1.TlsDefinition
 */
export type TlsDefinition = Message<"mochabugapis.adapt.plugins.v1.TlsDefinition"> & {
    /**
     * Select the TLS mode for the connection.
     *
     * @generated from field: mochabugapis.adapt.plugins.v1.TlsDefinition.Mode mode = 1;
     */
    mode: TlsDefinition_Mode;
    /**
     * The expected hostname for certificate verification (SNI - Server Name Indication).
     *
     * If present, the client will:
     * 1. Send this hostname in the TLS SNI extension during the handshake
     * 2. Verify that the server's certificate authenticates this specific hostname
     *
     * If not provided:
     * - The hostname is derived from the target upstream address
     * - For IP addresses, certificate verification may fail unless the cert includes the IP as a SAN
     *
     * ## Use Cases
     *
     * 1. **IP-based connections with hostname certificates:**
     *    - Upstream address: 192.168.1.100:443
     *    - certificate_host: "api.example.com"
     *    - Server presents cert for api.example.com
     *
     * 2. **Load balancers or proxies:**
     *    - Upstream address: lb.internal:443
     *    - certificate_host: "api.example.com"
     *    - Verify against the public hostname, not internal LB name
     *
     * 3. **Shared hosting / Virtual hosting:**
     *    - Multiple services on same IP, different certs via SNI
     *    - Server selects correct certificate based on SNI hostname
     *
     * ## Certificate Verification
     *
     * The server certificate must contain this hostname in either:
     * - Common Name (CN) field
     * - Subject Alternative Name (SAN) extension
     *
     * ## Format
     *
     * Must be a valid hostname (DNS name), not an IP address.
     * Examples: "api.example.com", "service.internal", "*.example.com" (for wildcard matching)
     *
     * @generated from field: optional string certificate_host = 2;
     */
    certificateHost?: string | undefined;
};
/**
 * TLS configuration defining the security requirements for upstream connections.
 *
 * Supports two authentication modes. CA bundles live in runtime config because
 * HTTP proxy settings use bindings to reference user-scoped certificate material.
 *
 * ## Security Model
 *
 * - CA bundles: MUST be in config
 * - Private keys and client certificates: MUST be in config
 *
 * ## Mode Descriptions
 *
 * MODE_SERVER_ONLY: Validate server's certificate (standard HTTPS)
 * - Client verifies server identity
 * - Server does not verify client
 * - Common for public APIs
 *
 * MODE_MTLS: Mutual authentication (both parties verify each other)
 * - Client verifies server identity AND presents its own certificate
 * - Server verifies client identity
 * - Common for B2B integrations, internal services
 *
 * @generated from message mochabugapis.adapt.plugins.v1.TlsDefinition
 */
export type TlsDefinitionJson = {
    /**
     * Select the TLS mode for the connection.
     *
     * @generated from field: mochabugapis.adapt.plugins.v1.TlsDefinition.Mode mode = 1;
     */
    mode?: TlsDefinition_ModeJson;
    /**
     * The expected hostname for certificate verification (SNI - Server Name Indication).
     *
     * If present, the client will:
     * 1. Send this hostname in the TLS SNI extension during the handshake
     * 2. Verify that the server's certificate authenticates this specific hostname
     *
     * If not provided:
     * - The hostname is derived from the target upstream address
     * - For IP addresses, certificate verification may fail unless the cert includes the IP as a SAN
     *
     * ## Use Cases
     *
     * 1. **IP-based connections with hostname certificates:**
     *    - Upstream address: 192.168.1.100:443
     *    - certificate_host: "api.example.com"
     *    - Server presents cert for api.example.com
     *
     * 2. **Load balancers or proxies:**
     *    - Upstream address: lb.internal:443
     *    - certificate_host: "api.example.com"
     *    - Verify against the public hostname, not internal LB name
     *
     * 3. **Shared hosting / Virtual hosting:**
     *    - Multiple services on same IP, different certs via SNI
     *    - Server selects correct certificate based on SNI hostname
     *
     * ## Certificate Verification
     *
     * The server certificate must contain this hostname in either:
     * - Common Name (CN) field
     * - Subject Alternative Name (SAN) extension
     *
     * ## Format
     *
     * Must be a valid hostname (DNS name), not an IP address.
     * Examples: "api.example.com", "service.internal", "*.example.com" (for wildcard matching)
     *
     * @generated from field: optional string certificate_host = 2;
     */
    certificateHost?: string;
};
/**
 * Describes the message mochabugapis.adapt.plugins.v1.TlsDefinition.
 * Use `create(TlsDefinitionSchema)` to create a new message.
 */
export declare const TlsDefinitionSchema: GenMessage<TlsDefinition, {
    jsonType: TlsDefinitionJson;
}>;
/**
 * Mode specifies which TLS configuration to use.
 *
 * @generated from enum mochabugapis.adapt.plugins.v1.TlsDefinition.Mode
 */
export declare enum TlsDefinition_Mode {
    /**
     * Default value. Invalid.
     *
     * @generated from enum value: MODE_UNSPECIFIED = 0;
     */
    UNSPECIFIED = 0,
    /**
     * Mutual TLS: Both client and server authenticate each other.
     *
     * Configuration requirements:
     * - CA bundle: REQUIRED in pluginservices runtime TLS state
     * - Client certificate: REQUIRED in pluginservices runtime TLS state
     * - Client private key: REQUIRED in pluginservices runtime TLS state
     *
     * Use when:
     * - Upstream service requires client certificate authentication
     * - Both parties need strong cryptographic authentication
     * - Common in B2B APIs, internal microservices, banking/financial APIs
     *
     * @generated from enum value: MODE_MTLS = 1;
     */
    MTLS = 1,
    /**
     * Server-only validation: Client verifies server identity.
     *
     * Configuration requirements:
     * - CA bundle: REQUIRED in pluginservices runtime TLS state
     * - Client certificate: NOT used
     * - Client private key: NOT used
     *
     * Use when:
     * - Standard HTTPS with server authentication only
     * - Upstream uses self-signed or internal CA certificates
     * - Want to pin specific CA certificates for security
     * - Most common mode for external APIs
     *
     * @generated from enum value: MODE_SERVER_ONLY = 2;
     */
    SERVER_ONLY = 2
}
/**
 * Mode specifies which TLS configuration to use.
 *
 * @generated from enum mochabugapis.adapt.plugins.v1.TlsDefinition.Mode
 */
export type TlsDefinition_ModeJson = "MODE_UNSPECIFIED" | "MODE_MTLS" | "MODE_SERVER_ONLY";
/**
 * Describes the enum mochabugapis.adapt.plugins.v1.TlsDefinition.Mode.
 */
export declare const TlsDefinition_ModeSchema: GenEnum<TlsDefinition_Mode, TlsDefinition_ModeJson>;
//# sourceMappingURL=http_proxy_service_pb.d.ts.map