New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 864366 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

Make sure blink::SecurityOrigin and url::Origin agree on what is opaque

Project Member Reported by dcheng@chromium.org, Jul 17

Issue description

Currently, it's possible to configure URL schemes in such a way that Blink believes the origin is not opaque while url::Origin thinks it is opaque: for example, externalfile: URLs are treated as opaque by url::Origin while blink::SecurityOrigin does not treat them as opaque.

Previously, this was not a huge issue: we would always need to go from Blink -> non-Blink, which would convert it to an opaque url::Origin if needed, then send it over IPC.

However, with Mojo in Blink, we can now send blink::SecurityOrigin over IPC directly. This trips the validation logic: when we deserialize a url.mojom.Origin to a url::Origin, we validate that the opaqueness of the url::Origin matches the opaque bit. This fails when sending an externalfile: URL...
 
In particular, SecurityOrigin::ToUrlOrigin uses url::Origin::CreateFromCanonicalizedTuple, which returns a default-constructed url::Origin if it deems a SchemeHostPort invalid. It's not obvious to me whether this was intended to return a unique origin, or whether it was intended to represent failure. (It's somewhat odd to me that url::Origin() is how unique origins are represented.)
(SchemeHostPort considers anything with a non-standard scheme to be invalid.)

Sign in to add a comment