New Transparent capture is in preview. Record every app's traffic with no proxy configuration, on Windows, macOS and Linux. Learn more

addBasicAuthenticationAction Action

High level helper that encodes a username and password as an RFC 7617 Basic credential and attaches it to outgoing requests.

Basic authentication is older than most modern APIs and still keeps showing up in internal tools, status pages, and legacy services. addBasicAuthenticationAction is the friendliest way to attach it from Fluxzy: type a username and password, scope them to a host, and let the proxy handle the base64 encoding for every matching request.

When to use this action

Use addBasicAuthenticationAction when you want Fluxzy to compute the RFC 7617 base64 encoding for you rather than typing out an Authorization: Basic header by hand. It is the most ergonomic choice for users who do not want to think about encoding rules or the credentials format string.

Typical situations include:

  • Quickly trying out a protected staging endpoint from a browser without changing application code.
  • Letting a non technical teammate edit a YAML rule with plain username and password fields.
  • Forwarding requests from a tool that supports proxying but not Basic auth, such as a static download utility or an old CLI.

The action evaluates on requestHeaderReceivedFromClient. Pair it with a hostFilter so the credential never reaches services that do not own it.

Real world examples

Authenticate to a staging environment

Drop the credential in for a single host so the browser, scripts, and SDKs all benefit without touching their own configuration.

rules:
- filter:
    typeKind: HostFilter
    pattern: staging.example.com
  actions:
  - typeKind: AddBasicAuthenticationAction
    username: qa-runner
    password: review-build-pass

Use a different identity per environment

Two rules cover staging and production with distinct credentials, helpful when reproducing role specific bugs.

rules:
- filter:
    typeKind: HostFilter
    pattern: staging.api.example.com
  actions:
  - typeKind: AddBasicAuthenticationAction
    username: qa
    password: qa-secret
- filter:
    typeKind: HostFilter
    pattern: api.example.com
  actions:
  - typeKind: AddBasicAuthenticationAction
    username: prod-readonly
    password: prod-readonly-secret

Combine Basic auth with a forced TLS version

Some legacy endpoints require TLS 1.2 plus Basic auth. Stack the two actions in one rule.

rules:
- filter:
    typeKind: HostFilter
    pattern: legacy.example.com
  actions:
  - typeKind: ForceTlsVersionAction
    tlsVersion: Tls12
  - typeKind: AddBasicAuthenticationAction
    username: legacy
    password: legacy-secret

Reference

addBasicAuthenticationAction

Description

Add a basic authentication (RFC 7617) to incoming exchanges with an username and a password

Evaluation scope

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

YAML configuration name

addBasicAuthenticationAction

Settings

The following table describes the customizable properties available for this action:

Property Type Description DefaultValue
username string
password string

Example of usage

The following examples apply this action to any exchanges

Add a basic authentication with username lilou and password multipass.

rules:
- filter:
    typeKind: AnyFilter
  actions:
  - typeKind: AddBasicAuthenticationAction
    username: lilou
    password: multipass

.NET reference

View definition of AddBasicAuthenticationAction for .NET integration.

See also

This action has no related action

Frequently asked questions

What is the difference between this action and addAuthorizationBasicAction?

Both result in an Authorization: Basic header. addBasicAuthenticationAction is the higher level helper that exposes username and password directly, while addAuthorizationBasicAction is the lower level header writer.

Is the credential persisted in any other place than the YAML?

No. Fluxzy reads the values from the rule file at evaluation time. Treat the file like any other secret and keep it out of public repositories.

How do I send the credential only when the upstream challenges with 401?

Fluxzy does not parse the 401 to retry. Apply the action unconditionally with a tight filter, or attach it to a responseHeaderFilter that targets the second pass of a retry sensitive client.

Will special characters in the password be encoded correctly?

Yes. The action encodes user:password as UTF-8 before base64, which covers the modern RFC 7617 rules. Avoid raw newline or null bytes in the password.

Learn more about Fluxzy rules