mirror of
https://github.com/PR0M3TH3AN/bitlogin.git
synced 2026-10-27 08:31:21 +00:00
thePR0M3TH3ANandClaude Sonnet 5
1dbb4fca51
Some NIP-07 extensions install window.nostr as a non-configurable, non-writable property to stop another script from overwriting it. claimSigner() did a plain, unguarded `window.nostr = ...` assignment, so on a page where such an extension is active, this threw "Cannot assign to read only property 'nostr' of object '#<Window>'" -- and because it ran synchronously before dispatching bitlogin-login or moving to the dashboard screen, it froze account creation/import at the final "verify your recovery phrase" step, with that raw TypeError as the only feedback shown. Reported from a real BitRoad integration session. claimSigner() and releaseSigner() now catch this and return false instead of throwing; connectedCallback's initial claim attempt is guarded the same way. Every caller (registration, login, recovery, password change) now completes sign-in regardless -- a host page using this element's own methods directly (getPublicKey/signEvent/nip44Encrypt/nip44Decrypt) was never actually affected by a failed window.nostr takeover, only a page that reads window.nostr itself. The dashboard now shows a plain-language warning when this happens, reusing the existing rollback/relay-disagreement warning banner mechanism. Also fixed while auditing this area: the "Copy" button on the generated- password screen silently did nothing if the clipboard write failed (e.g. Firefox's stricter permissions, an unfocused document) -- it now flashes "Copied" or "Copy failed -- select the text manually" either way. Verified live in Chrome: reproduced the exact crash by locking down window.nostr the way a real extension does, confirmed account creation/import now completes end-to-end (in both the standalone demo and embedded in BitRoad) with the new warning shown instead of a stuck flow. Co-Authored-By: Claude Sonnet 5 <[email protected]>