According to the spec, websocket request has 'websocket' as the mode
that differs than 'no-cors' mode. So websocket request should always
contain credentials.
Differential Revision: https://phabricator.services.mozilla.com/D177396
According to the spec, websocket request has 'websocket' as the mode
that differs than 'no-cors' mode. So websocket request should always
contain credentials.
Differential Revision: https://phabricator.services.mozilla.com/D177396
This patch replaces the previous ContractID-based lookup system for protocol
handlers, and replaces it with a new custom system in nsIOService. It will be
pre-populated with non-overridable static protocol handlers using the
StaticComponents infrastructure added in the previous part, and callers can
also dynamically register new protocol handlers at runtime.
This new system is intended to provide access to the default port and
non-dynamic protocol flags off-main-thread, by requiring these values to be
provided up-front as constants, rather than getting them from the xpcom
interface. The data is then guarded by an RWLock.
Callers which look up specific handlers by their contractID are not changed, as
the contract IDs for existing handlers have not been changed, so the lookup
will still succeed.
This change as-implemented breaks the nsGIOProtocolHandler on Linux, as it
removes the special code which would try to use that handler for some
protocols. This will be fixed in a later part by making the
nsGIOProtocolHandler use the dynamic registration APIs to register and
un-register protocol handlers at runtime in response to the GIO pref.
Differential Revision: https://phabricator.services.mozilla.com/D162804
This patch replaces the previous ContractID-based lookup system for protocol
handlers, and replaces it with a new custom system in nsIOService. It will be
pre-populated with non-overridable static protocol handlers using the
StaticComponents infrastructure added in the previous part, and callers can
also dynamically register new protocol handlers at runtime.
This new system is intended to provide access to the default port and
non-dynamic protocol flags off-main-thread, by requiring these values to be
provided up-front as constants, rather than getting them from the xpcom
interface. The data is then guarded by an RWLock.
Callers which look up specific handlers by their contractID are not changed, as
the contract IDs for existing handlers have not been changed, so the lookup
will still succeed.
This change as-implemented breaks the nsGIOProtocolHandler on Linux, as it
removes the special code which would try to use that handler for some
protocols. This will be fixed in a later part by making the
nsGIOProtocolHandler use the dynamic registration APIs to register and
un-register protocol handlers at runtime in response to the GIO pref.
Differential Revision: https://phabricator.services.mozilla.com/D162804
The previous part introduced a new mechanism to track the triggering remote
type for a specific load in a reliable way. This adds some basic checks based
on the triggering remote type to the nsContentSecurityManager, while also
providing the potential infrastructure to expand these checks in the future.
As these checks are performed before some other content security checks (to
ensure that they are performed before InitialSecurityCheckDone() is checked),
they may reject a load which would otherwise have been rejected by a later
check. For this reason, the diagnostic assertions added in this part are only
fired if the check appears as though it would otherwise have succeeded. This
check is not fully accurate, however, so may miss some cases.
This is important, as we have some tests, such as service worker navigation
tests, which will try to load file:/// URIs in content processes, and only fail
in the later content security checks.
For now, no checks are performed for non-document loads, though that may change
in the future.
Differential Revision: https://phabricator.services.mozilla.com/D161199
Spec: https://html.spec.whatwg.org/multipage/#coep:coep-credentialless
Credentialless is a new cross-origin embedder policy which allows us
to not enforcing CORP when loading cross-origin resources while
providing SharedArrayBuffer.
There are two main things involved here:
1. Fetching cross-origin no-CORS resources omits credentials
- This is done by applying `LOAD_ANONYMOUS` flag to the request
2. Other requests sent with credentials require the server's explicit
permission through the CORS protocol or the CORS header
- This is done by expanding `ProcessCrossOriginResourcePolicyHeader`
function to apply the necessary checks.
Differential Revision: https://phabricator.services.mozilla.com/D147802
Spec: https://html.spec.whatwg.org/multipage/#coep:coep-credentialless
Credentialless is a new cross-origin embedder policy which allows us
to not enforcing CORP when loading cross-origin resources while
providing SharedArrayBuffer.
There are two main things involved here:
1. Fetching cross-origin no-CORS resources omits credentials
- This is done by applying `LOAD_ANONYMOUS` flag to the request
2. Other requests sent with credentials require the server's explicit
permission through the CORS protocol or the CORS header
- This is done by expanding `ProcessCrossOriginResourcePolicyHeader`
function to apply the necessary checks.
Differential Revision: https://phabricator.services.mozilla.com/D147802
Spec: https://html.spec.whatwg.org/multipage/#coep:coep-credentialless
Credentialless is a new cross-origin embedder policy which allows us
to not enforcing CORP when loading cross-origin resources while
providing SharedArrayBuffer.
There are two main things involved here:
1. Fetching cross-origin no-CORS resources omits credentials
- This is done by applying `LOAD_ANONYMOUS` flag to the request
2. Other requests sent with credentials require the server's explicit
permission through the CORS protocol or the CORS header
- This is done by expanding `ProcessCrossOriginResourcePolicyHeader`
function to apply the necessary checks.
Differential Revision: https://phabricator.services.mozilla.com/D147802
Given the Fetch spec, the TAO check algorithm has been updated to
be more restricted. This patch updates the algorithm to match the
spec.
Differential Revision: https://phabricator.services.mozilla.com/D146737
This is a bit of a refactor.
We'll keep the spagetthi code for existing checks, to be able
to easily iterate and pref-flip if things fail later in the cycle.
This also resolves bug 1638770 and removes the "disallow all"
-pref that proved not be a useful approach anyway.
Differential Revision: https://phabricator.services.mozilla.com/D145411
This copies over the behavior for style & subdocument restrictions.
Admittedly, with this if/else spagetthi, it would be preferable to
turn this into restriction levels or lump some of the known-to-be-safe
prefs together, but I would prefer we wait a couple of cycles to
make sure this makes it all the way to release before we refactor.
Differential Revision: https://phabricator.services.mozilla.com/D145306
