meme ja4 fingerprint cloudflare

Share Your Browser Session with curl: The Session Capture/Replay Feature in Fluxzy (CLI and Desktop)

You've just logged into a web application through your browser, and now you need to hit some authenticated API endpoints using curl or another command-line tool. What follows is usually a tedious dance: open DevTools, find the right cookies, copy them carefully, paste them into your terminal, and hope you didn't miss anything. If the session refreshes? Start over.

What if your tools could simply inherit your browser's authenticated session automatically?

That's exactly what Fluxzy's Session Capture/Replay feature does. By routing both your browser and CLI tools through the same proxy, Fluxzy captures authentication data from one client and applies it to requests from others. Just authenticate once in your browser, then use any HTTP client as if it were already logged in.

In this article, I'll walk you through how this feature works, how to set it up, and share some practical examples you can reproduce on your own machine. Fluxzy CLI is open source and available at github.com/haga-rak/fluxzy.core, so you can follow along or dig into the implementation yourself.


How It Works

The concept is straightforward: Fluxzy acts as a man-in-the-middle proxy that maintains a shared session store.

┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│   Browser   │────>│   Fluxzy    │────>│   Server    │
│  (login)    │<────│   Proxy     │<────│  (github)   │
└─────────────┘     │             │     └─────────────┘
                    │  Session    │
                    │   Store     │
┌─────────────┐     │  ┌───────┐  │
│    curl     │────>│  │cookies│  │
│  (API call) │<────│  │headers│  │
└─────────────┘     │  └───────┘  │
                    └─────────────┘

Here's the flow:

  1. Capture phase: When a server responds with Set-Cookie headers or other authentication headers, the CaptureSessionAction intercepts and stores them, organized by domain. When captureRequestCookies is set also, cookies sent by the client are captured as well.

  2. Storage: Session data lives in memory, isolated per domain to prevent cross-site leakage.

  3. Replay phase: When any client makes a request to a matching domain, the ApplySessionAction automatically injects the stored session data into the outgoing request.

  4. Shared access: All clients routing through the proxy share the same session store, meaning your curl commands benefit from your browser's authentication.


Setting Up Session Capture/Replay

Step 1: Create a Rule File

Fluxzy uses YAML rule files to configure its behavior. Create a file named session-rules.yaml with the following content:

rules:
- filter:
    typeKind: AnyFilter
  actions:
  - typeKind: CaptureSessionAction
    captureCookies: true
    captureRequestCookies: true
    captureHeaders:
    - Authorization
    - X-CSRF-Token
    - X-Auth-Token
- filter:
    typeKind: RequestHeaderFilter
    headerName: User-Agent
    pattern: curl
    operation: Contains
  actions:
  - typeKind: ApplySessionAction
    applyCookies: true
    applyHeaders: true
    mergeWithExisting: true

This configuration tells Fluxzy to capture cookies and specific headers from any traffic, then apply them to subsequent cur request.

Step 2: Start Fluxzy

Launch the proxy with your rule file (download here):

fluxzy start -l 127.0.0.1:8080 -r session-rules.yaml -p

Pro tip: Add the --system-proxy flag to automatically register Fluxzy as your system proxy, avoiding the need to configure each browser individually:

For the lazy, here's a one-liner that does it all:

fluxzy start -l 127.0.0.1:8080 --system-proxy -p -R << 'EOF'
rules:
- filter:
    typeKind: AnyFilter
  actions:
  - typeKind: CaptureSessionAction
    captureCookies: true
    captureRequestCookies: true
    captureHeaders:
    - Authorization
    - X-CSRF-Token
    - X-Auth-Token
- filter:
    typeKind: RequestHeaderFilter
    headerName: User-Agent
    pattern: curl
    operation: Contains
  actions:
  - typeKind: ApplySessionAction
    applyCookies: true
    applyHeaders: true
    mergeWithExisting: true
EOF

Step 3: Configure Your Browser

If you used --system-proxy: Skip this step! Your browser is already configured. If you didn't use --system-proxy: Set your browser to use 127.0.0.1:8080 as its HTTP/HTTPS proxy. Most browsers allow this in their network settings, or you can use a proxy-switching extension for convenience

Step 4: Authenticate

Navigate to github.com in your browser and log in as you normally would. Fluxzy silently captures the session cookies in the background.

Step 5: Use curl with Your Session

Now the magic happens. Run a curl command through the proxy:

curl -x 127.0.0.1:8080 https://github.com/_side-panels/user.json

Without any manual cookie handling, this returns your authenticated user data. Fluxzy automatically injected the session cookies captured from your browser.


Action Reference

CaptureSessionAction

Controls what gets captured from server responses.

Property Type Default Description
captureCookies bool true Capture cookies from Set-Cookie headers
captureHeaders string[] [] Header names to capture, e.g., ["Authorization"]

ApplySessionAction

Controls what gets injected into outgoing requests.

Property Type Default Description
applyCookies bool true Apply stored cookies to requests
applyHeaders bool true Apply stored headers to requests
mergeWithExisting bool true Merge with client's existing cookies (vs replace entirely)
sourceDomain string null Use session from a different domain (useful for subdomains)

ClearSessionAction

Allows programmatic session clearing.

Property Type Default Description
domain string null Domain to clear (null clears all sessions)

For Fluxzy Desktop Users

Just paste the YAML rules above into a new rule set via the "Manage Rules" dialog in Fluxzy Desktop. Start capturing, authenticate in your browser, then run curl commands as shown.

rules:
- filter:
    typeKind: AnyFilter
  actions:
  - typeKind: CaptureSessionAction
    captureCookies: true
    captureRequestCookies: true
    captureHeaders:
    - Authorization
    - X-CSRF-Token
    - X-Auth-Token
- filter:
    typeKind: RequestHeaderFilter
    headerName: User-Agent
    pattern: curl
    operation: Contains
  actions:
  - typeKind: ApplySessionAction
    applyCookies: true
    applyHeaders: true
    mergeWithExisting: true

Practical Examples

Sharing Sessions Across Subdomains

Many applications use a main domain for authentication but serve APIs from a subdomain. You can configure Fluxzy to share sessions across them:

rules:
  # Capture from main domain
  - filter:
      typeKind: HostFilter
      pattern: "example.com"
    actions:
      - typeKind: CaptureSessionAction
        captureCookies: true

  # Apply to API subdomain using parent domain session
  - filter:
      typeKind: HostFilter
      pattern: "api.example.com"
    actions:
      - typeKind: ApplySessionAction
        applyCookies: true
        sourceDomain: "example.com"

Capturing Authorization Headers from Requests

Sometimes the Authorization header is set by the client (perhaps via a browser extension) rather than received from the server. Fluxzy can capture these too:

rules:
  - filter:
      typeKind: HostFilter
      pattern: "api.example.com"
    actions:
      - typeKind: CaptureSessionAction
        captureCookies: true
        captureHeaders:
          - Authorization

Clearing Sessions on Logout

You can trigger a session clear when hitting specific paths:

rules:
  - filter:
      typeKind: PathFilter
      pattern: "/logout"
    actions:
      - typeKind: ClearSessionAction
        domain: "github.com"

Replace vs Merge Mode

By default, captured cookies merge with any cookies the client already provides. If you want the captured session to completely override client cookies:

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

Advantages and Trade-offs

Why Use This Feature

  • Eliminates copy-paste workflows: No more hunting through DevTools for cookies and tokens.
  • Works with any HTTP client: curl, wget, httpie, custom scripts—anything that can use a proxy.
  • Real-time session updates: Token refreshes and new cookies are captured automatically.
  • Domain isolation: Sessions are strictly separated by domain, preventing accidental cross-site leakage.
  • Thread-safe: Concurrent requests from multiple clients are handled correctly.

Limitations to Consider

  • Security-sensitive: Session data is stored in memory. Anyone with access to the proxy can use captured sessions.
  • No persistence: Sessions are intentionally lost when the proxy restarts (a security feature, not a bug).
  • Local network only: This only works for clients routing through the proxy on the same machine or network.
  • Cookie scope simplification: Path-scoped cookies may be applied more broadly than the server intended.

Security Considerations

This feature is designed for development and testing environments. Keep these points in mind:

  1. Never expose the proxy to untrusted networks. Anyone who can route through your proxy gains access to captured sessions.

  2. Sessions are memory-only. By design, nothing persists to disk, reducing the risk of session data being recovered later.

  3. Sessions clear on restart. Stopping Fluxzy wipes the session store.

  4. Domain isolation is enforced. A captured session for github.com will never leak to gitlab.com.


Wrapping Up

The Session Capture/Replay feature transforms Fluxzy from a debugging proxy into a session-sharing hub. Whether you're testing authenticated APIs, automating workflows that normally require browser sessions, or just tired of copying cookies around, this feature can save you significant time.

Set up takes just a few minutes: create a rule file, start the proxy, authenticate in your browser, and your CLI tools are ready to go. Give it a try on your next project and see how much friction it removes from your workflow.


Published at Wednesday, 31 December 2025