Bearer tokens drive most modern APIs, and most tools that capture HTTP traffic still leave token handling to the client. Fluxzy lets you push that responsibility into the proxy, which means scripts and apps can talk to OAuth gated services without ever knowing about the token, and you can swap identities with a single edit to a YAML file.
Use addAuthorizationBearerAction when an upstream API expects an Authorization: Bearer <token> header and you want Fluxzy to attach it instead of the client. This is especially useful when the token is short lived or rotated by a separate process.
Typical situations include:
The action evaluates on requestHeaderReceivedFromClient. Combine it with a hostFilter so the token never leaves the intended domain.
Scope the token to the API host so it never reaches third party services. Useful when reverse engineering a public web app that calls a token gated backend.
rules:
- filter:
typeKind: HostFilter
pattern: api.payments.example.com
actions:
- typeKind: AddAuthorizationBearerAction
token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.payload.signature
Two rules with different host filters keep the right credential on the right environment, no client code change required.
rules:
- filter:
typeKind: HostFilter
pattern: staging-api.example.com
actions:
- typeKind: AddAuthorizationBearerAction
token: staging-token-here
- filter:
typeKind: HostFilter
pattern: api.example.com
actions:
- typeKind: AddAuthorizationBearerAction
token: production-token-here
Combine with the negation of hasAuthorizationBearerFilter to only add a token when one is missing, leaving authenticated clients untouched.
rules:
- filter:
typeKind: FilterCollection
operation: And
children:
- typeKind: HostFilter
pattern: api.example.com
- typeKind: HasAuthorizationBearerFilter
inverted: true
actions:
- typeKind: AddAuthorizationBearerAction
token: fallback-development-token
Add Authorization Bearer token to the request header.
Evaluation scope defines the timing where this filter will be applied.
requestHeaderReceivedFromClient This scope occurs the moment fluxzy parsed the request header receiveid from client
addAuthorizationBearerAction
The following table describes the customizable properties available for this action:
| Property | Type | Description | DefaultValue |
|---|---|---|---|
| token | string |
The following examples apply this action to any exchanges
Add Authorization Bearer token to the request header.
rules:
- filter:
typeKind: AnyFilter
actions:
- typeKind: AddAuthorizationBearerAction
token: your_token_here
View definition of AddAuthorizationBearerAction for .NET integration.
This action has no related action
No. The token in the YAML is used as is. Pair this action with a build step that fetches a fresh token, writes it into the rule file, and restarts the capture.
It appends a new header. If both headers exist, most servers honour the first. Use deleteRequestHeaderAction first if you need a clean override.
Yes. Define a setVariableAction that reads from your environment, then reference the variable in the token field.
It is meant for capture, debugging, and lab use. Anyone with access to the rule file can read the token, so do not commit production credentials to a shared repository.