Repository navigation
fix: JWT provider restores the signed session after a reload; host-only cookies on IP hosts; version 19.5.2 - #208
Merged
Conversation
…ly cookies on IP hosts; version 19.5.2 - On a Signed-mode /sessions answer for an identified session without a live grant, with no token held and a JWT provider set, ask the provider once per session load and identify with its token through setUserJwt (identity_mismatch recovery included). Respects signedModeIdentifySent, the one-minute signed-mode interval, the provider backoff and the single in-flight provider call. A null token sends nothing. A provider set after the session loaded is asked as well. - setGleapCookie / eraseGleapCookie omit the domain attribute on IPv4 and IPv6 hosts (the browser rejected domain=0.1 for 127.0.0.1), so the session and grant cookies are stored there. Domain hosts and localhost unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This was referenced Nov 7, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes two defects in the identity-token release (19.5.1) that showed up in today's production test.
1. A JWT provider on its own never restores a signed session after a reload (LOW–MEDIUM)
Problem. Identify with
setUserJwt, then reload with onlysetUserJwtProviderset and no grant cookie (IP host, or cookie deleted)./sessionsanswersidentity: { mode: 'signed', signed: false }, but the SDK never asks the provider and never identifies. The user stays unsigned: the server limits them to 14 days of history, and Kai treats them as unverified. The cause:needsSignedModeIdentify/identifyForSignedModeIfNeededneedlastIdentify.userHash, which lives in memory only, andwithFreshIdentifyreturns early when there is nolastIdentify.Fix (
src/GleapSession.js). Two new methods,needsSignedModeProviderIdentifyandidentifyWithProviderForSignedModeIfNeeded.identifyForSignedModeIfNeededuses them when it has no held identify to send. Once per session load (signedModeProviderAsked, reset inclearSession), the SDK asks the provider when all of these hold:session.userIdset)signedModeIdentifySentand the one-minuteGRANT_REFRESH_MIN_INTERVAL_MSguard allow itThe token goes through
setUserJwt→identifySession, the same path as an app-supplied token. That path markssignedModeIdentifySent, so at most one identify goes out per load. A token for another user goes through the normalidentity_mismatchrecovery.nulltoken sends nothing.setUserJwtProvideralso runs the check when the session is already loaded, so a provider set after the/sessionsanswer still works.index.d.ts, theGleap.jsJSDoc and the README now say the provider also restores the signed session after a reload.2. Cookies are never stored on IP-address hosts (LOW)
Problem.
setGleapCookiewrotedomain=removeSubDomain(host). On127.0.0.1that isdomain=0.1, and on[::1]:8080it isdomain=[. The browser rejects these cookies, so the session cookie and the grant cookie were lost.Fix (
src/GleapHelper.js). A newcookieDomainFor(host)returnsnullfor IPv4 and for IPv6 (bracketed or bare).setGleapCookieanderaseGleapCookiethen leave out the domain attribute, which makes the cookie host-only, and erasing it still works. Domain hosts are unchanged.localhostalso keepsdomain=localhost, which worked in testing.Tests
src/GleapSession.test.js, new describe block "signed mode restored by the JWT provider alone":null→ nothing sent, nothing logged, not asked againidentity_mismatchrecovery/sessionsanswer is askedWithout the fix, all 8 provider tests fail.
src/GleapHelper.test.js: acookieDomainFortable (domains,.co.uk,localhost, IPv4, IPv6 with and without brackets or port), host-only write and erase on127.0.0.1:8080and[::1]:8080, and an unchanged Domain onexample.comandlocalhost.Results
npm test -- --ci: 37 suites, 695 tests, all pass.npm run build: compiles. The only warnings are the existing webpack bundle-size warnings.npm pack --dry-run: OK (gleap-19.5.2.tgz).Versioning
package.json,package-lock.jsonandCHANGELOG.mdmove to 19.5.2, following the repo convention. Not released: no tag, no npm publish. Build output is not committed. Note that the CDN deploys on every push to master, so merging this ships it to sdk.gleap.io.🤖 Generated with Claude Code