The problem
A properly secured session cookie is HttpOnly, which means JavaScript cannot read it, which means document.cookie returns nothing for it, which means most test tools, built on JavaScript running in the page, are blind to it. So the very cookie that proves a secure login succeeded is the one your existing tests cannot confirm. You end up asserting the user looks logged in, never that the secure session cookie was actually set.
The idea
The most important cookie is the one your scripts cannot see. Kane CLI reads it anyway, so you can finally assert the secure session exists.
What you will catch
- A secure HttpOnly session cookie a page script cannot read
- Confirmation that a real session was set, not just that the UI looks logged in
- The cookie that proves the secure half of authentication worked
How it works
Kane CLI reads cookies below the page, so HttpOnly cookies are fully visible to it even though document.cookie hides them. You assert the cookie exists and carries the HttpOnly flag.
Run it now
kane-cli --tui
# then paste this objective:
Go to https://github.com and let it load.
Assert: at least one HttpOnly cookie is set.Or one line, for CI or sharing
kane-cli run "Go to https://github.com and let it load.
Assert: at least one HttpOnly cookie is set." --agentWhat prints
Example run. Your numbers will vary by site, build and run. The PASS / FAIL and the zeros are the stable result, the raw timings and counts are illustrative.
▶ navigate + settle ok ▶ assert HttpOnly cookie set found 2 ✓ PASS RESULT PASS exit 0 ~45s ~6 to 10 credits
Adapt it to your app
Go to <your app> and log in.
Assert: a cookie named "<your session cookie>" exists and is HttpOnly.Why it works
HttpOnly cookies are invisible to document.cookie by design, but Kane CLI reads cookies at the protocol level, so it sees them.
What it unlocks
You can finally assert the secure session itself, not a proxy for it. The login test checks the thing that actually matters, that an HttpOnly session cookie was set.
