@mochabug/adapt-plugin-toolkit/dist/genproto/mochabugapis/adapt/plugins/v1/http_proxy_service_pb.d.ts

The API toolkit to facilitate mochabug adapt plugin development

import type { GenEnum, GenFile, GenMessage } from "@bufbuild/protobuf/codegenv2";
import type { File, FileJson } from "./file_pb";
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" but NOT the root domain
     *   - "*.example.com" matches "api.example.com" but NOT "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;
    /**
     * 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;
    };
};
/**
 * 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" but NOT the root domain
     *   - "*.example.com" matches "api.example.com" but NOT "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;
    };
};
/**
 * 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 with flexible CA bundle placement.
 *
 * ## Security Model
 *
 * - Public certificates (CA bundles): Can be in definition OR config
 * - Private keys and client certificates: MUST be in config (secrets)
 *
 * ## 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;
    /**
     * Optional CA bundle for server certificate validation.
     *
     * ## Why CA Bundle in Definition?
     *
     * CA bundles contain PUBLIC certificates (not secrets), so they can be safely
     * embedded in the plugin definition. This reduces configuration burden on users
     * when the CA bundle is known ahead of time.
     *
     * ## When to Use This Field
     *
     * Set the CA bundle in the definition when:
     * - The upstream service uses a self-signed certificate
     * - The upstream uses a private/internal Certificate Authority
     * - You want to pin specific CA certificates for security
     * - The CA bundle is static and known at plugin authoring time
     *
     * ## When to Use TlsConfig.ca_bundle Instead
     *
     * Leave this empty and use TlsConfig.ca_bundle when:
     * - Different users need different CA bundles
     * - The CA bundle is dynamic or environment-specific
     * - Users want to override the plugin's default CA bundle
     *
     * ## Configuration Rules
     *
     * For MODE_SERVER_ONLY:
     * - At least one CA bundle must be provided (either here OR in TlsConfig)
     * - If set here: users don't need to provide TlsConfig.ca_bundle
     * - If NOT set here: users MUST provide TlsConfig.ca_bundle
     *
     * For MODE_MTLS:
     * - Same CA bundle rules as MODE_SERVER_ONLY
     * - Users must ALSO provide client certificate and private_key in TlsConfig
     *
     * ## Precedence
     *
     * If CA bundle is provided in both the definition AND TlsConfig:
     * - TlsConfig.ca_bundle takes precedence (config overrides definition)
     * - This allows users to override the plugin's default CA bundle if needed
     *
     * ## Format
     *
     * The CA bundle must be in PEM format (same as TlsConfig.ca_bundle).
     * If a certificate chain is presented, the root CA must be included.
     *
     * IF this points to a file on the disk, then it will be loaded from there.
     *
     * @generated from field: optional mochabugapis.adapt.plugins.v1.File ca_bundle = 3;
     */
    caBundle?: File;
};
/**
 * TLS configuration defining the security requirements for upstream connections.
 *
 * Supports two authentication modes with flexible CA bundle placement.
 *
 * ## Security Model
 *
 * - Public certificates (CA bundles): Can be in definition OR config
 * - Private keys and client certificates: MUST be in config (secrets)
 *
 * ## 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;
    /**
     * Optional CA bundle for server certificate validation.
     *
     * ## Why CA Bundle in Definition?
     *
     * CA bundles contain PUBLIC certificates (not secrets), so they can be safely
     * embedded in the plugin definition. This reduces configuration burden on users
     * when the CA bundle is known ahead of time.
     *
     * ## When to Use This Field
     *
     * Set the CA bundle in the definition when:
     * - The upstream service uses a self-signed certificate
     * - The upstream uses a private/internal Certificate Authority
     * - You want to pin specific CA certificates for security
     * - The CA bundle is static and known at plugin authoring time
     *
     * ## When to Use TlsConfig.ca_bundle Instead
     *
     * Leave this empty and use TlsConfig.ca_bundle when:
     * - Different users need different CA bundles
     * - The CA bundle is dynamic or environment-specific
     * - Users want to override the plugin's default CA bundle
     *
     * ## Configuration Rules
     *
     * For MODE_SERVER_ONLY:
     * - At least one CA bundle must be provided (either here OR in TlsConfig)
     * - If set here: users don't need to provide TlsConfig.ca_bundle
     * - If NOT set here: users MUST provide TlsConfig.ca_bundle
     *
     * For MODE_MTLS:
     * - Same CA bundle rules as MODE_SERVER_ONLY
     * - Users must ALSO provide client certificate and private_key in TlsConfig
     *
     * ## Precedence
     *
     * If CA bundle is provided in both the definition AND TlsConfig:
     * - TlsConfig.ca_bundle takes precedence (config overrides definition)
     * - This allows users to override the plugin's default CA bundle if needed
     *
     * ## Format
     *
     * The CA bundle must be in PEM format (same as TlsConfig.ca_bundle).
     * If a certificate chain is presented, the root CA must be included.
     *
     * IF this points to a file on the disk, then it will be loaded from there.
     *
     * @generated from field: optional mochabugapis.adapt.plugins.v1.File ca_bundle = 3;
     */
    caBundle?: FileJson;
};
/**
 * 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: Set in TlsDefinition.ca_bundle OR TlsConfig.ca_bundle (at least one required)
     * - Client certificate: REQUIRED in TlsConfig.certificate
     * - Client private key: REQUIRED in TlsConfig.private_key
     *
     * 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: Set in TlsDefinition.ca_bundle OR TlsConfig.ca_bundle (at least one required)
     * - 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>;
/**
 * The actual TLS configuration containing runtime secrets.
 *
 * This provides the secret/dynamic parts of the TLS configuration that cannot
 * be embedded in the plugin definition (private keys, user-specific certificates).
 *
 * ## Relationship to TlsDefinition
 *
 * - TlsDefinition: Defines the TLS mode and optionally includes the CA bundle (public cert)
 * - TlsConfig: Provides runtime secrets (private keys, client certificates)
 *
 * ## Configuration Requirements
 *
 * For MODE_SERVER_ONLY:
 * - ca_bundle: Required if NOT provided in TlsDefinition.ca_bundle
 * - certificate: NOT used
 * - private_key: NOT used
 *
 * For MODE_MTLS:
 * - ca_bundle: Required if NOT provided in TlsDefinition.ca_bundle
 * - certificate: REQUIRED (client certificate for mutual TLS)
 * - private_key: REQUIRED (client private key for mutual TLS)
 *
 * @generated from message mochabugapis.adapt.plugins.v1.TlsConfig
 */
export type TlsConfig = Message<"mochabugapis.adapt.plugins.v1.TlsConfig"> & {
    /**
     * Optional CA bundle for server certificate validation.
     *
     * The CA bundle in PEM format containing one or more trusted Certificate Authorities.
     * The content of the file must be PEM format after decoding.
     * If a certificate chain is presented, the root CA must be included.
     *
     * ## When to Provide This
     *
     * REQUIRED if TlsDefinition.ca_bundle is NOT set.
     * OPTIONAL if TlsDefinition.ca_bundle is set (this will override the definition's CA bundle).
     *
     * ## Override Behavior
     *
     * If both TlsDefinition.ca_bundle and TlsConfig.ca_bundle are provided:
     * - This config value takes precedence
     * - Allows users to override the plugin author's default CA bundle
     *
     * ## Use Cases for Override
     *
     * - User's organization has different root CAs
     * - Testing with different certificate chains
     * - Environment-specific CA requirements
     *
     * @generated from field: optional mochabugapis.adapt.plugins.v1.File ca_bundle = 1;
     */
    caBundle?: File;
    /**
     * Optional client certificate for mutual TLS authentication.
     *
     * The certificate in PEM format used to authenticate the client to the server.
     * The content of the file must be PEM format after decoding.
     * If a certificate chain is presented, the client certificate must be the first one.
     *
     * REQUIRED if TlsDefinition.mode is MODE_MTLS.
     * MUST NOT be provided if TlsDefinition.mode is MODE_SERVER_ONLY.
     *
     * @generated from field: optional mochabugapis.adapt.plugins.v1.File certificate = 2;
     */
    certificate?: File;
    /**
     * Optional client private key for mutual TLS authentication.
     *
     * The private key in PEM format corresponding to the client certificate.
     * The content of the file must be PEM format after decoding.
     * The content must contain a PRIVATE KEY block.
     *
     * REQUIRED if TlsDefinition.mode is MODE_MTLS.
     * MUST NOT be provided if TlsDefinition.mode is MODE_SERVER_ONLY.
     *
     * @generated from field: optional mochabugapis.adapt.plugins.v1.File private_key = 3;
     */
    privateKey?: File;
};
/**
 * The actual TLS configuration containing runtime secrets.
 *
 * This provides the secret/dynamic parts of the TLS configuration that cannot
 * be embedded in the plugin definition (private keys, user-specific certificates).
 *
 * ## Relationship to TlsDefinition
 *
 * - TlsDefinition: Defines the TLS mode and optionally includes the CA bundle (public cert)
 * - TlsConfig: Provides runtime secrets (private keys, client certificates)
 *
 * ## Configuration Requirements
 *
 * For MODE_SERVER_ONLY:
 * - ca_bundle: Required if NOT provided in TlsDefinition.ca_bundle
 * - certificate: NOT used
 * - private_key: NOT used
 *
 * For MODE_MTLS:
 * - ca_bundle: Required if NOT provided in TlsDefinition.ca_bundle
 * - certificate: REQUIRED (client certificate for mutual TLS)
 * - private_key: REQUIRED (client private key for mutual TLS)
 *
 * @generated from message mochabugapis.adapt.plugins.v1.TlsConfig
 */
export type TlsConfigJson = {
    /**
     * Optional CA bundle for server certificate validation.
     *
     * The CA bundle in PEM format containing one or more trusted Certificate Authorities.
     * The content of the file must be PEM format after decoding.
     * If a certificate chain is presented, the root CA must be included.
     *
     * ## When to Provide This
     *
     * REQUIRED if TlsDefinition.ca_bundle is NOT set.
     * OPTIONAL if TlsDefinition.ca_bundle is set (this will override the definition's CA bundle).
     *
     * ## Override Behavior
     *
     * If both TlsDefinition.ca_bundle and TlsConfig.ca_bundle are provided:
     * - This config value takes precedence
     * - Allows users to override the plugin author's default CA bundle
     *
     * ## Use Cases for Override
     *
     * - User's organization has different root CAs
     * - Testing with different certificate chains
     * - Environment-specific CA requirements
     *
     * @generated from field: optional mochabugapis.adapt.plugins.v1.File ca_bundle = 1;
     */
    caBundle?: FileJson;
    /**
     * Optional client certificate for mutual TLS authentication.
     *
     * The certificate in PEM format used to authenticate the client to the server.
     * The content of the file must be PEM format after decoding.
     * If a certificate chain is presented, the client certificate must be the first one.
     *
     * REQUIRED if TlsDefinition.mode is MODE_MTLS.
     * MUST NOT be provided if TlsDefinition.mode is MODE_SERVER_ONLY.
     *
     * @generated from field: optional mochabugapis.adapt.plugins.v1.File certificate = 2;
     */
    certificate?: FileJson;
    /**
     * Optional client private key for mutual TLS authentication.
     *
     * The private key in PEM format corresponding to the client certificate.
     * The content of the file must be PEM format after decoding.
     * The content must contain a PRIVATE KEY block.
     *
     * REQUIRED if TlsDefinition.mode is MODE_MTLS.
     * MUST NOT be provided if TlsDefinition.mode is MODE_SERVER_ONLY.
     *
     * @generated from field: optional mochabugapis.adapt.plugins.v1.File private_key = 3;
     */
    privateKey?: FileJson;
};
/**
 * Describes the message mochabugapis.adapt.plugins.v1.TlsConfig.
 * Use `create(TlsConfigSchema)` to create a new message.
 */
export declare const TlsConfigSchema: GenMessage<TlsConfig, {
    jsonType: TlsConfigJson;
}>;
/**
 * The actual HTTP proxy configuration containing runtime values
 *
 * This message provides the actual configuration values for the HTTP proxy service,
 * including TLS certificates and template variable values for header injection.
 *
 * ## Relationship to HttpProxyDefinition
 *
 * - HttpProxyDefinition: Defines the schema (which headers to inject, template syntax, TLS mode)
 * - HttpProxyConfig: Provides the actual values (certificates, variable values)
 *
 * ## Example
 *
 * Given a definition with:
 * - inject_headers["Authorization"].template.template = "Bearer %ACCESS_TOKEN%"
 * - tls.mode = MODE_SERVER_ONLY
 *
 * The config would provide:
 * - tls_config.ca_bundle = <actual CA certificate>
 * - template_variables["ACCESS_TOKEN"] = "eyJhbGci..." (the actual token)
 *
 * @generated from message mochabugapis.adapt.plugins.v1.HttpProxyConfig
 */
export type HttpProxyConfig = Message<"mochabugapis.adapt.plugins.v1.HttpProxyConfig"> & {
    /**
     * The actual TLS configuration with certificates and private keys.
     *
     * REQUIRED if HttpProxyDefinition.tls is set.
     * MUST NOT be set if HttpProxyDefinition.tls is not set.
     *
     * For MODE_SERVER_ONLY:
     * - Provide only ca_bundle
     * - Leave certificate and private_key empty
     *
     * For MODE_MTLS:
     * - Provide ca_bundle, certificate, AND private_key
     *
     * @generated from field: optional mochabugapis.adapt.plugins.v1.TlsConfig tls_config = 1;
     */
    tlsConfig?: TlsConfig;
    /**
     * Template variable values for dynamic header injection, organized by header name.
     *
     * This provides the actual values for template variables used in HttpProxyDefinition.inject_headers.
     * Each header that uses template variables needs its variables resolved here.
     *
     * ## Structure
     *
     * Outer map key: HTTP header name (must match a key in HttpProxyDefinition.inject_headers)
     * Outer map value: Map of variable names to their actual values for that specific header
     *
     * This structure mirrors HttpProxyDefinition.inject_headers, making it clear
     * which variables belong to which header template.
     *
     * ## Variable Name Requirements
     *
     * Variable names must match the %VARIABLE% patterns used in the header's template:
     * - Start with a letter or underscore
     * - Contain only letters, numbers, and underscores
     * - Case-sensitive (e.g., %ACCESS_TOKEN% requires variable name "ACCESS_TOKEN")
     *
     * ## Examples
     *
     * Given a definition with:
     * - inject_headers["Authorization"].template = "Bearer %ACCESS_TOKEN%"
     * - inject_headers["X-Correlation"].template = "%TENANT_ID%:%USER_ID%"
     *
     * The config must provide:
     * - header_variables["Authorization"]["ACCESS_TOKEN"] = "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..."
     * - header_variables["X-Correlation"]["TENANT_ID"] = "org_123"
     * - header_variables["X-Correlation"]["USER_ID"] = "user_456"
     *
     * ## Security
     *
     * All values are stored securely and encrypted at rest.
     * The HeaderTemplate.plaintext flag (in the definition) controls whether
     * the variable value is treated as a secret or shown in logs/UI.
     *
     * ## Variable Resolution Process
     *
     * Users of the plugin are prompted to provide values for all template variables.
     * For system services, the plugin author provides the values programmatically.
     *
     * During configuration, it is fully transparent to users:
     * - Which hostname the request will be sent to (from allowed_hosts)
     * - Which headers are being injected
     * - What template variables are required
     * - Whether each variable is a secret or plaintext
     *
     * Users see exactly what data they are providing and where it will be sent.
     *
     * ## Runtime Behavior
     *
     * If a variable referenced in a header template is missing from this config,
     * the header injection will fail at runtime and the request will not be sent.
     *
     * ## Validation
     *
     * - Header names in this map MUST match headers in HttpProxyDefinition.inject_headers
     * - All variables referenced in each header's template must be provided
     * - Extra variables (not referenced in the template) are ignored
     *
     * @generated from field: map<string, mochabugapis.adapt.plugins.v1.HeaderVariables> header_variables = 2;
     */
    headerVariables: {
        [key: string]: HeaderVariables;
    };
};
/**
 * The actual HTTP proxy configuration containing runtime values
 *
 * This message provides the actual configuration values for the HTTP proxy service,
 * including TLS certificates and template variable values for header injection.
 *
 * ## Relationship to HttpProxyDefinition
 *
 * - HttpProxyDefinition: Defines the schema (which headers to inject, template syntax, TLS mode)
 * - HttpProxyConfig: Provides the actual values (certificates, variable values)
 *
 * ## Example
 *
 * Given a definition with:
 * - inject_headers["Authorization"].template.template = "Bearer %ACCESS_TOKEN%"
 * - tls.mode = MODE_SERVER_ONLY
 *
 * The config would provide:
 * - tls_config.ca_bundle = <actual CA certificate>
 * - template_variables["ACCESS_TOKEN"] = "eyJhbGci..." (the actual token)
 *
 * @generated from message mochabugapis.adapt.plugins.v1.HttpProxyConfig
 */
export type HttpProxyConfigJson = {
    /**
     * The actual TLS configuration with certificates and private keys.
     *
     * REQUIRED if HttpProxyDefinition.tls is set.
     * MUST NOT be set if HttpProxyDefinition.tls is not set.
     *
     * For MODE_SERVER_ONLY:
     * - Provide only ca_bundle
     * - Leave certificate and private_key empty
     *
     * For MODE_MTLS:
     * - Provide ca_bundle, certificate, AND private_key
     *
     * @generated from field: optional mochabugapis.adapt.plugins.v1.TlsConfig tls_config = 1;
     */
    tlsConfig?: TlsConfigJson;
    /**
     * Template variable values for dynamic header injection, organized by header name.
     *
     * This provides the actual values for template variables used in HttpProxyDefinition.inject_headers.
     * Each header that uses template variables needs its variables resolved here.
     *
     * ## Structure
     *
     * Outer map key: HTTP header name (must match a key in HttpProxyDefinition.inject_headers)
     * Outer map value: Map of variable names to their actual values for that specific header
     *
     * This structure mirrors HttpProxyDefinition.inject_headers, making it clear
     * which variables belong to which header template.
     *
     * ## Variable Name Requirements
     *
     * Variable names must match the %VARIABLE% patterns used in the header's template:
     * - Start with a letter or underscore
     * - Contain only letters, numbers, and underscores
     * - Case-sensitive (e.g., %ACCESS_TOKEN% requires variable name "ACCESS_TOKEN")
     *
     * ## Examples
     *
     * Given a definition with:
     * - inject_headers["Authorization"].template = "Bearer %ACCESS_TOKEN%"
     * - inject_headers["X-Correlation"].template = "%TENANT_ID%:%USER_ID%"
     *
     * The config must provide:
     * - header_variables["Authorization"]["ACCESS_TOKEN"] = "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..."
     * - header_variables["X-Correlation"]["TENANT_ID"] = "org_123"
     * - header_variables["X-Correlation"]["USER_ID"] = "user_456"
     *
     * ## Security
     *
     * All values are stored securely and encrypted at rest.
     * The HeaderTemplate.plaintext flag (in the definition) controls whether
     * the variable value is treated as a secret or shown in logs/UI.
     *
     * ## Variable Resolution Process
     *
     * Users of the plugin are prompted to provide values for all template variables.
     * For system services, the plugin author provides the values programmatically.
     *
     * During configuration, it is fully transparent to users:
     * - Which hostname the request will be sent to (from allowed_hosts)
     * - Which headers are being injected
     * - What template variables are required
     * - Whether each variable is a secret or plaintext
     *
     * Users see exactly what data they are providing and where it will be sent.
     *
     * ## Runtime Behavior
     *
     * If a variable referenced in a header template is missing from this config,
     * the header injection will fail at runtime and the request will not be sent.
     *
     * ## Validation
     *
     * - Header names in this map MUST match headers in HttpProxyDefinition.inject_headers
     * - All variables referenced in each header's template must be provided
     * - Extra variables (not referenced in the template) are ignored
     *
     * @generated from field: map<string, mochabugapis.adapt.plugins.v1.HeaderVariables> header_variables = 2;
     */
    headerVariables?: {
        [key: string]: HeaderVariablesJson;
    };
};
/**
 * Describes the message mochabugapis.adapt.plugins.v1.HttpProxyConfig.
 * Use `create(HttpProxyConfigSchema)` to create a new message.
 */
export declare const HttpProxyConfigSchema: GenMessage<HttpProxyConfig, {
    jsonType: HttpProxyConfigJson;
}>;
/**
 * Variable values for a specific header's template substitution.
 *
 * @generated from message mochabugapis.adapt.plugins.v1.HeaderVariables
 */
export type HeaderVariables = Message<"mochabugapis.adapt.plugins.v1.HeaderVariables"> & {
    /**
     * Map of variable name to value.
     *
     * Key: Variable name matching %VAR_NAME% in the header's template
     * Value: The actual value to substitute
     *
     * @generated from field: map<string, string> variables = 1;
     */
    variables: {
        [key: string]: string;
    };
};
/**
 * Variable values for a specific header's template substitution.
 *
 * @generated from message mochabugapis.adapt.plugins.v1.HeaderVariables
 */
export type HeaderVariablesJson = {
    /**
     * Map of variable name to value.
     *
     * Key: Variable name matching %VAR_NAME% in the he