New Fluxzy v2 just shipped. Electron is out, Tauri is in. gRPC ready, 3x smaller install. Learn more

applySessionAction Action

Replay cookies and headers captured earlier by captureSessionAction so a new client can resume an authenticated session without logging in.

Re running a login flow for every test is wasteful and brittle. applySessionAction lets Fluxzy capture a real authenticated session once and replay it for any subsequent client, which turns a flaky end to end suite into something deterministic and means scripts can drive APIs without ever knowing about the auth handshake.

When to use this action

Use applySessionAction when you want a new client, script, or test run to inherit a session that was captured earlier with captureSessionAction. Instead of re running login steps, Fluxzy attaches the right cookies and headers as requests flow through.

Typical situations include:

  • Driving an API from a script after the user logs in through a browser, no need to script the auth flow.
  • Replaying a captured session against a different environment for parity testing.
  • Letting QA repeat an end to end scenario without burning a real OTP each time.
  • Sharing a session across several tools by routing them all through Fluxzy.

The action evaluates on requestHeaderReceivedFromClient. Use sourceDomain to scope which captured session is reused when several were stored.

Real world examples

Apply cookies to every outgoing request

Simplest form: replay every captured cookie on every matching request, merging with whatever the client already sent.

rules:
- filter:
    typeKind: HostFilter
    pattern: app.example.com
  actions:
  - typeKind: ApplySessionAction
    applyCookies: true
    mergeWithExisting: true

Replay both cookies and Authorization headers

Useful when the original login produced both a session cookie and a bearer token. Both are replayed together.

rules:
- filter:
    typeKind: HostFilter
    pattern: api.example.com
  actions:
  - typeKind: ApplySessionAction
    applyCookies: true
    applyHeaders: true
    mergeWithExisting: true

Reuse a session from a specific source domain

When the capture covered several apps, restrict the replay to the session captured for one of them.

rules:
- filter:
    typeKind: HostFilter
    pattern: api.example.com
  actions:
  - typeKind: ApplySessionAction
    applyCookies: true
    applyHeaders: true
    mergeWithExisting: true
    sourceDomain: auth.example.com

Reference

applySessionAction

Description

Apply captured session data to requests. Adds cookies from session store and optionally applies stored headers. Works in conjunction with CaptureSessionAction.

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

applySessionAction

Settings

This action has no specific characteristic

Example of usage

The following examples apply this action to any exchanges

Apply session cookies to requests.

rules:
- filter:
    typeKind: AnyFilter
  actions:
  - typeKind: ApplySessionAction
    applyCookies: true
    mergeWithExisting: true

Apply all session data (cookies and headers).

rules:
- filter:
    typeKind: AnyFilter
  actions:
  - typeKind: ApplySessionAction
    applyCookies: true
    applyHeaders: true
    mergeWithExisting: true

Apply session from a specific domain.

rules:
- filter:
    typeKind: AnyFilter
  actions:
  - typeKind: ApplySessionAction
    applyCookies: true
    applyHeaders: true
    mergeWithExisting: true
    sourceDomain: auth.example.com

Replace existing cookies entirely with session cookies.

rules:
- filter:
    typeKind: AnyFilter
  actions:
  - typeKind: ApplySessionAction
    applyCookies: true
    applyHeaders: true

.NET reference

View definition of ApplySessionAction for .NET integration.

See also

The following actions are related to this action:

Frequently asked questions

How is the session data stored between runs?

Sessions live in the Fluxzy process memory by default. To persist them across runs, capture into a session store backed by disk or replay during the same Fluxzy session that captured them.

What if the original cookie has expired?

The cookie is still replayed verbatim. Servers will reject it the same way they would reject any expired credential. Re run the capture step to refresh the session.

Can I edit the captured session before replaying it?

Yes. The captured data is accessible to other actions, so you can combine applySessionAction with updateRequestHeaderAction or setRequestCookieAction to tweak specific fields.

Does this work for OAuth bearer tokens?

Yes, as long as the original capture included the Authorization header. Make sure captureSessionAction lists Authorization in its captureHeaders and that applyHeaders is true here.

Learn more about Fluxzy rules