WICG
Synchronous operation and capability discovery
More of a question than an issue at this point, but I'm looking to see if there is any way during session establishment to do synchronous operations after a session is registered. Use case is as follows:
Browser loads a page which contains client-side JS. The client-side JS uses a fetch call to contact a server URL, which returns the sec-session-registration response header, along with some (unimportant) response body.
At this point the browser asynchronously registers a DBSC session using the start session endpoint, however the JS code that ran the original fetch operation doesn't know this, and doesn't have a way to "wait" until either:
- that asynchronous registration completes
- it can know that the browser either doesn't support DBSC or can't complete DBSC registration at the moment
My use case is that I would like to make additional fetch calls, following the one that kicked off the DBSC sec-session-response header, but only after the browser has had a chance to register a DBSC session if it is able.
How might this be achieved?
If there was a getCapabilities API, as well as a way to register a callback function that fired when either DBSC registration completed, or when DBSC registration failed - that might do it, but open to other ideas.
This is indeed the big pain point of our header-based API. What we're doing in automated testing is this:
- Have the registration endpoint set a cookie visible to JS
- Set a timeout by which you expect registration to have finished
- Check for the presence of the cookie after the timeout
We haven't found it necessary to know this information for protecting against cookie theft, though. In our setup, the "login" endpoint (the one serving Sec-Session-Registration) gives a long-lived cookie. The registration endpoint can then make the cookie short-lived, and we mark the old long-lived cookie invalid on the server-side. If DBSC is not supported, the user continues using a long-lived cookie for authentication. If DBSC is supported, there's a window where they're authenticating with a long-lived cookie, but only until registration completes a few seconds later and they transition to DBSC cookies.
Can you say more about your use case for knowing whether DBSC registration completed or not?
Thanks for that information Daniel. I can employ the same technique in my use case for now, however it would still be useful to know when DBSC was completed (or if its not going to be completed at all) to minimize the time waiting on the browser, or the chance of a race condition during registration. The scenario is a reasonably simple one - we want to influence the real-time user experience based on whether the DBSC session was registered or not.
Having been exploring this more in the last week, a discovery API to know if the browser is DBSC-capable is about the bare minimum that would really help. At least in that case I could have the browser just "not wait" at all for a cookie that is never going to come from the server's registration endpoint.