-
Notifications
You must be signed in to change notification settings - Fork 313
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose environment ids? #643
Comments
Is this satisfied by |
That doesn't give a client access to its own ID, does it? |
I think we're going to try moving the clients API into all client types. Would |
Each global has .clients I guess? Seems a little weird to put it there. |
It would be nice we could provide an API to snapshot the current window as a full What about something like:
Seems if you have synchronous access to a window global we could simply mint the full Client object immediately. Edit: Worker could could do |
No need to pass in the global then. You could just use the constructor from the correct global. Anyway, that seems reasonable. |
Although, shouldn't it be asynchronous? Or is synchronous for the current global okay? |
I thought it might be nice to be able to specify a same-origin iframe global, etc. But sure. We could also have a snapshot method or something that returns a Client.
I think synchronous from the current global should be ok. AFAIK all the values on client are available synchronously in other places. For example, |
Yes, for the iframe case you can just do |
Now that we have IDs to identify environments, perhaps environments should have access to them too? E.g. might be useful for sites that allow different session per open document.
Also, we should probably say that environment ids should be unique per origin, but should not be globally unique or something like that, so they can not really be used as additional entropy to identify the user.
The text was updated successfully, but these errors were encountered: