CacheStorage/Cache should require SecureContext
Categories
(Core :: Storage: Cache API, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox103 | --- | fixed |
People
(Reporter: bkelly, Assigned: saschanaz)
References
(Blocks 2 open bugs)
Details
(Keywords: dev-doc-complete, Whiteboard: DWS_NEXT)
Attachments
(3 files, 4 obsolete files)
Reporter | ||
Comment 1•10 years ago
|
||
Comment 2•10 years ago
|
||
Comment 3•10 years ago
|
||
Reporter | ||
Comment 4•10 years ago
|
||
Reporter | ||
Comment 5•10 years ago
|
||
Reporter | ||
Comment 7•10 years ago
|
||
Comment 9•10 years ago
|
||
Reporter | ||
Comment 10•10 years ago
|
||
Reporter | ||
Comment 11•10 years ago
|
||
Comment 12•10 years ago
|
||
Reporter | ||
Comment 14•10 years ago
|
||
Comment 15•10 years ago
|
||
Comment 16•10 years ago
|
||
Comment 17•10 years ago
|
||
Comment 18•10 years ago
|
||
Reporter | ||
Comment 19•10 years ago
|
||
Comment 20•10 years ago
|
||
Comment 21•10 years ago
|
||
Reporter | ||
Comment 22•10 years ago
|
||
Comment 23•10 years ago
|
||
Reporter | ||
Comment 24•10 years ago
|
||
Comment 25•10 years ago
|
||
Reporter | ||
Comment 26•10 years ago
|
||
Comment 27•10 years ago
|
||
Comment 28•10 years ago
|
||
Comment 29•10 years ago
|
||
Comment 32•10 years ago
|
||
Updated•10 years ago
|
Updated•10 years ago
|
Reporter | ||
Updated•10 years ago
|
Updated•9 years ago
|
Reporter | ||
Comment 33•9 years ago
|
||
Comment 34•8 years ago
|
||
Reporter | ||
Comment 35•8 years ago
|
||
Comment 36•8 years ago
|
||
Updated•6 years ago
|
Comment 38•6 years ago
|
||
Updated•6 years ago
|
Updated•6 years ago
|
Comment 39•6 years ago
|
||
Comment 40•6 years ago
|
||
Comment 41•6 years ago
|
||
Comment 42•6 years ago
|
||
Updated•5 years ago
|
Updated•5 years ago
|
Comment 43•5 years ago
|
||
(In reply to Perry Jiang [:perry] from comment #41)
Update: CacheStorages, Cache, and global "caches" will only be exposed on
secure contexts, and using any of those in private browsing (in secure
context) will throw a SecurityError. Exposing those interfaces/attributes on
secure contexts in turn broke many tests, which are in the process of being
fixed
Is this a description of the current state of what we implemented (and thus we are ok) or of the desired behavior (and thus we should work and change this bug's title/description)?
Comment 44•5 years ago
|
||
Ah, no, this is the desired behavior and not what's current implemented. IIRC the broken tests were never fully fixed.
Assignee | ||
Comment 45•3 years ago
•
|
||
using any of those in private browsing (in secure context) will throw a SecurityError.
Can this be tracked separately? It shouldn't block adding SecureContext.
Assignee | ||
Comment 46•3 years ago
|
||
Updated•3 years ago
|
Updated•3 years ago
|
Comment 47•3 years ago
|
||
Comment 48•3 years ago
•
|
||
Backed out for causing xpcshell failures on test_originInit.js
Backout link: https://hg.mozilla.org/integration/autoland/rev/3b63167e1ba02d11da697044acfb3e9da79b2041
Failure log(s): https://treeherder.mozilla.org/logviewer?job_id=363586908&repo=autoland&lineNumber=3407 // https://treeherder.mozilla.org/logviewer?job_id=363586448&repo=autoland
Failure line(s): TEST-UNEXPECTED-FAIL | dom/cache/test/xpcshell/test_originInit.js | xpcshell return code: 0 // TEST-UNEXPECTED-FAIL | toolkit/components/antitracking/test/browser/browser_partitionedDOMCache.js | Test timed out
Updated•3 years ago
|
Assignee | ||
Comment 49•3 years ago
|
||
Depends on D134560
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 50•3 years ago
|
||
Depends on D135548
Assignee | ||
Comment 51•3 years ago
|
||
Depends on D135565
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Assignee | ||
Comment 52•3 years ago
|
||
Some report: There are TONS OF tests that assumes existence of caches
on non-secure context. Probably better to add something like dom.caches.non_secure_context.enabled
or just reuse dom.caches.testing.enabled
(although this one has other potentially unwanted effects), and use [Func]
to conditionally expose cache things by checking mGlobal->IsSecureContext()
and the flag.
Assignee | ||
Comment 53•2 years ago
|
||
Assignee | ||
Comment 54•2 years ago
|
||
Depends on D148327
Comment 55•2 years ago
|
||
Comment 56•2 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/c1b395cec03f
https://hg.mozilla.org/mozilla-central/rev/97a7a79776de
Comment 57•2 years ago
|
||
FF103 docs work for this can be tracked in https://github.com/mdn/content/issues/17475
My understanding is that this change means that the global caches object is only available in secure contexts (and this is what is use to get a CacheStorage
object and associated Cache
objects. So if you you're not in a secure context then the caches
object won't exist.
Further, the preference dom.caches.testing.enabled
and dom.serviceWorkers.testing.enabled
disable this requirement for a secure context to allow things to be tested more easily.
-
Is that about it?
-
The existing docs for CacheStorage (only, not
caches
orCache
) indicate secure context support was added in FF44. Is that an error? If not, what is the difference between what happened in FF44 and now? -
There are some comments about about Private Browsing. Is there anything we need to say about that? If so, what happens for PB in a secure context with
caches
? -
The docs for CacheStorage have a note:
Note: Chrome and Safari only expose
CacheStorage
to the windowed context over HTTPS. caches will be undefined unless an SSL certificate is configured.How does that differ from "in a secure context"? I.e. does that mean that even if localhost would normally be a secure context then it wouldn't work for Chrome because it requires HTTPS and a valid certificate in all cases? If so, I assume FF does not have this limitation.
Thanks!
Assignee | ||
Comment 58•2 years ago
•
|
||
Hi Hamish,
Is that about it?
Yup.
The existing docs for CacheStorage (only, not
caches
orCache
) indicate secure context support was added in FF44. Is that an error? If not, what is the difference between what happened in FF44 and now?
That kinda makes sense. Before this patch CacheStorage
is the one that has secure-context-related logic (its methods threw exception in non-secure context), and caches
just returned CacheStorage
without any error. But it certainly is confusing to devs, I'd rather mark them as supported and add notes about this.
There are some comments about about Private Browsing. Is there anything we need to say about that? If so, what happens for PB in a secure context with caches?
The work is happening but it's Nightly only and is actively changing. Please ignore that part for now. (Bug 1776109)
How does that differ from "in a secure context"? I.e. does that mean that even if localhost would normally be a secure context then it wouldn't work for Chrome because it requires HTTPS and a valid certificate in all cases? If so, I assume FF does not have this limitation.
I feel like that part is misleading, I don't think SecureContext checks certificates. caches
is available on https://expired.badssl.com/ on both Firefox and Chrome, so I'd just remove that note.
Thanks as always, and feel free to ask more whenever needed.
Comment 59•2 years ago
|
||
Thanks very much! I've taken your advice:
- Added secure context info to browser compat data for
caches
. The info is still there for CacheStorage, but IMO will do not harm since it still sends the same signal "don't use outside of a secure context". - Removed the note about HTTPS/certificate
- Added a release note mentioning what changed (caches et al require secure context, while previously you'd be handed a CacheStorage that would then throw in secure context). Did not mention the preference for testing - IMO it is "not intended for the arbitrary use".
- Did not comment on private browsing.
So very minimal changes. YOu can see them in https://github.com/mdn/content/issues/17475#issuecomment-1179904034 . Hope I got this right! Thanks again.
Description
•