Skip to main content

extract_tenant

tensor_wasm_api::middleware

Function extract_tenant 

Source 
pub fn extract_tenant(
    headers: &HeaderMap,
    cfg: TenantConfig,
) -> Result<TenantId, Response>
Expand description

Parse the X-TensorWasm-Tenant header into a TenantId, applying the configured policy.

Outcomes:

  • More than one X-TensorWasm-Tenant header present => Err(400 duplicate_tenant_header). HeaderMap::get returns only the first match, so an attacker behind a permissive proxy could send X-TensorWasm-Tenant: 1, X-TensorWasm-Tenant: 999 and confuse downstream observers about which tenant the request really belongs to. We reject outright before any single value is read.
  • Header absent + TENSOR_WASM_API_REQUIRE_TENANT=1 => Err(400 missing_tenant).
  • Header absent otherwise => Ok(TenantId(0)).
  • Header present but not a u64 => Err(400 invalid_tenant). The distinct invalid_tenant kind separates a malformed value from the legitimately-absent case so dashboards can alert on each class independently — a spike in invalid_tenant typically indicates a client bug or a probing attacker, whereas a spike in missing_tenant indicates a misconfigured client.