fix(auth, web): connect Auth emulator after reload when sessionStorage already has the origin - #18690
Conversation
…e already has the origin Skip connectAuthEmulator only when this JS Auth instance is already on the requested origin. Matching sessionStorage is not enough after a full page reload, especially on 127.0.0.1 where the early reconnect used to be skipped.
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. |
Description
On web,
useAuthEmulatorskippedconnectAuthEmulatorwhen sessionStorage already had the emulator origin from a previous page load. After a full reload the JS Auth instance is new and still points at production, so that skip sent traffic to prod (especially on127.0.0.1, where plugin init never reconnected).Skip only when this JS Auth instance is already on the requested origin (
emulatorConfig). Also re-apply the persisted origin on127.0.0.1/[::1]at plugin init, not justlocalhost.Related Issues
Checklist
///).melos run analyze) does not report any problems on my PR.Breaking Change