Boloop reading diagram (AI-generated): checking login along the browser, identity service, callback, session, and access permission path.
When migrating Boloop, pages may build successfully, but admin login still has its own failure modes. One concrete example: a parameter used to prevent redirect following is accepted fine in Node tests, but throws an exception when placed in the actual edge runtime.
This kind of issue can easily be masked by a simple 'Google login failed' message, leading to repeatedly checking keys, reconfiguring callbacks, or even loosening identity validation. What actually needed fixing this time was runtime compatibility handling for a request.
Login Is Not a Button but a Round-Trip Path
In Boloop's login implementation, the browser first initiates login to our site, then goes to Google; Google sends the authorization result back to our site's callback, the server exchanges the token, validates identity, and then creates a session. Every subsequent admin operation must re-check whether this session has permission.
Therefore, seeing Google's login page only proves the flow reached one segment. It doesn't prove the callback address is correct, that the token can be exchanged, or that the person returning is actually authorized to manage the site.
When migrating, I first cross-check three addresses: the official address the browser actually visits, the site address configured on the server, and the callback address registered in the Google client. Google requires the callback address to match the registered value exactly—protocol, case, and trailing slash are all within the matching scope. Google OpenID Connect Documentation
The address written at build time must also match the address read at service runtime. Changing only frontend environment variables won't automatically update the server's runtime configuration.
A Runtime Difference Missed by Node Tests
At the time, the troubleshooting clue landed on the token exchange phase: the application returned a 'service unavailable' result but didn't get a non-success response status from Google. This shifted the investigation direction from 'what error did Google return' to 'was the request even successfully sent'.
In the official workerd runtime used at that time, redirect: 'error' triggers Invalid redirect value. The original Node fetch stub not only accepted this option, but the test also asserted it was passed, so the green test didn't expose the incompatibility in the real environment.
The fix changed to redirect: 'manual' while keeping the rejection of non-success statuses. The goal remains not following service redirects: fail on receiving a 3xx instead of automatically forwarding sensitive requests to another address.
Then, using an isolated outbound stub, I checked normal responses, the entire 300–399 status range, and timeout failures in actual workerd. This test didn't use real Google credentials; it resolved the runtime compatibility proof, while real Google login still needs to be completed separately after deployment.
After Authentication, Permissions Still Need Confirmation
Google can prove account identity, but the site still needs to decide what that identity can do. Boloop separates admin identity binding from regular login—no automatic admin for the first login, and no reliance on identity headers passed by the browser as authorization basis.
Google's documentation defines sub as a stable account identifier and explicitly warns against using potentially changing email addresses as the user primary key. Boloop's admin check simultaneously verifies the pre-bound account identifier and the verified email; this is a site-specific permission rule, not a universal solution every site must adopt. Google Identity Claims Documentation
This part of acceptance must check both allow and deny: admins can access the admin interface, regular logged-in users cannot manage, and anonymous requests cannot read private data. Looking only at the admin's own success screen would miss permission boundaries.
What Happens When the Session Expires Mid-Edit
An isolated browser check for the migration candidate used a fictional identity and test records. The test first opened the edit form, entered an unsaved title, then let the session expire in another tab.
After save returns 401, the private form should be protected; after re-establishing the same authorized identity and re-verifying through the interface, unsaved input should still be retained, then normal saving can proceed. This checks one more thing that actually affects authors compared to 'can open admin after re-login': whether identity recovery also preserved work content.
The same round also checked anonymous entry, non-admin rejection, logout, and interface recovery when session reads fail. Since the Google provider was disabled in testing, these results cannot serve as acceptance results for real authorization popups and callbacks.
Checks I'll Run Before Migration Is Complete
First, initiate a complete login through the official entry point and confirm the callback ultimately returns to the correct admin. Then refresh the page to check if the session is still valid; after logout, re-accessing admin data should be denied. Finally, check regular accounts, session expiry, unsaved edit recovery, and storage bindings in the actual deployment environment.
When recording evidence, only leave phases, statuses, and publicly shareable error categories. Authorization codes, cookies, tokens, and full callback query strings should not become screenshot or article material.
This Boloop experience led me to break migration acceptance into three results: logic holds in test doubles, the target runtime can execute, and real accounts work on the official site. The three answer different questions. After a page successfully goes live, the login round-trip path is still worth walking through from the start.