A login flow can take dozens of redirects, popups, and token exchanges, and re running it for every test is painful. captureSessionAction lets Fluxzy quietly record the resulting cookies and tokens once, so that the rest of your tooling can pretend the login already happened and focus on the behaviour that actually matters.
Use captureSessionAction when you want Fluxzy to record an authenticated session in flight so it can be replayed later by applySessionAction. The capture is passive: nothing changes in the response that reaches the client, the proxy just remembers what it saw.
Typical situations include:
The action evaluates on responseHeaderReceivedFromRemote by default. Use captureRequestCookies to also harvest cookies present on incoming requests, which is what lets you grab an already authenticated session.
Run this once while a user logs in through the browser. The cookies are stored and ready for applySessionAction to replay.
rules:
- filter:
typeKind: HostFilter
pattern: auth.example.com
actions:
- typeKind: CaptureSessionAction
captureCookies: true
captureHeaders: []
Useful for APIs that combine cookie sessions with custom CSRF or anti forgery headers.
rules:
- filter:
typeKind: HostFilter
pattern: api.example.com
actions:
- typeKind: CaptureSessionAction
captureCookies: true
captureHeaders:
- Authorization
- X-CSRF-Token
- X-Auth-Token
If the user is already logged in when capture starts, no Set-Cookie will fly. Enable captureRequestCookies to harvest what the client is sending.
rules:
- filter:
typeKind: HostFilter
pattern: app.example.com
actions:
- typeKind: CaptureSessionAction
captureCookies: true
captureRequestCookies: true
captureHeaders: []
Capture session data from responses. Captures Set-Cookie headers and optionally other headers like Authorization. Can also capture cookies from request headers for intercepting ongoing sessions. Stored data can be replayed using ApplySessionAction.
Evaluation scope defines the timing where this filter will be applied.
responseHeaderReceivedFromRemote This scope occurs the moment fluxzy has done parsing the response header.
captureSessionAction
This action has no specific characteristic
The following examples apply this action to any exchanges
Capture cookies from responses.
rules:
- filter:
typeKind: AnyFilter
actions:
- typeKind: CaptureSessionAction
captureCookies: true
captureHeaders: []
Capture cookies and Authorization header.
rules:
- filter:
typeKind: AnyFilter
actions:
- typeKind: CaptureSessionAction
captureCookies: true
captureHeaders:
- Authorization
Capture cookies and multiple custom headers.
rules:
- filter:
typeKind: AnyFilter
actions:
- typeKind: CaptureSessionAction
captureCookies: true
captureHeaders:
- Authorization
- X-CSRF-Token
- X-Auth-Token
Capture cookies from request headers (for ongoing sessions).
rules:
- filter:
typeKind: AnyFilter
actions:
- typeKind: CaptureSessionAction
captureCookies: true
captureRequestCookies: true
captureHeaders: []
View definition of CaptureSessionAction for .NET integration.
The following actions are related to this action:
In the running Fluxzy process by default. The data is available to other rules in the same session. For persistent storage, capture into a session store backed by disk before the process exits.
No. The action is read only. Cookies and headers reach the client untouched while a copy is stored for later replay.
Capture only the headers you intend to replay. Authorization, X-CSRF-Token, and custom auth tokens are the usual candidates. Avoid capturing things like Date or Content-Length which would break a replay.
Yes. Each capture is keyed by the source domain on the exchange, so several login flows can be captured side by side and replayed independently.