-
Notifications
You must be signed in to change notification settings - Fork 67
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 origin attribute in PortalActivateEvent #162
Comments
Interesting suggestion. I think that the existing API surface is sufficient to allow authors to figure out what's going on here, but plumbing the origin here seems like it would be reasonably straightforward and be much easier to use for authors. @a4sriniv, you looked at messaging APIs; WDYT of this? |
I think this is a good idea. I think of the data field in the portalactivate event as an author friendly alternative to just using postMessage before activation, so it makes sense to me to mirror the origin aspect of the message event (and it shouldn't be difficult to implement). But on a related note, we also have targetOrigin specified as part of the postMessage API parameters, which checks the origin of the destination frame before delivering the message. Do we need something similar for activate? |
An interesting thought. What would the semantics of that be if the guest contents navigates? Also, should it only limit delivery of the activation data, or should it block activation altogether? |
targetOrigin Is also good to add :) |
My initial thought here was to fail the activation (resolve the promise with an error) as a guard against the guest contents navigating without the host's knowledge. |
Is this still a good idea, given our desire to limit cross-origin communication? |
Yeah I don't think this applies anymore. I think we're going to omit portalactivatedata from the activate event for cross-origin portal activations. |
Sounds good. Let's close this for now. I filed #196 to track speccing those restrictions. |
Are we dropping adoption in the activate event? Otherwise, it seems like the page should know the origin of the page it's adopting. |
Ahh, I remembered this issue as using targetOrigin to limit which origins get activate data, I forgot about actually using the targetOrigin to stop activation altogether. |
I'm a bit confused where this landed. I think there are several proposals being floated:
Are either of these good ideas? Both of them? |
We could defer adding this to later if we wanted to, though I suspect it will eventually be useful especially in combination with There might be a world in which we become worried about sites setting using their hostname to convey information (though I'm not convinced that is convenient enough that it would actually be in widespread use), but that will arise elsewhere in the platform (location.ancestorOrigins etc) and mitigations exist (like heuristically or unconditionally censoring to eTLD+1). |
I can imagine a future where a site is expecting a data in
PortalActivateEvent
from trusted site.But
PortalActivateEvent
can be triggered by any site (similar tomessage
event), therefore origin attribute has to be exposed inPortalActivateEvent
. Otherwise it'll be an XSS nightmare 😊The text was updated successfully, but these errors were encountered: