Bug 243324 - webkit-pdfjs-viewer URI scheme should not be blocked by CSP
Summary: webkit-pdfjs-viewer URI scheme should not be blocked by CSP
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: PDF (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Patrick Griffis
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2022-07-28 16:44 PDT by Michael Catanzaro
Modified: 2022-08-02 10:09 PDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Catanzaro 2022-07-28 16:44:34 PDT
Try loading: https://www.ameren.com/-/media/rates/files/missouri/uecsheet54rate1mres.ashx

It gets blocked by the page's CSP:

[Error] Refused to load webkit-pdfjs-viewer://pdfjs/web/viewer.html?file=#pagemode=none because it appears in neither the frame-src directive nor the default-src directive of the Content Security Policy.
[Error] Refused to load webkit-pdfjs-viewer://pdfjs/extras/adwaita/style.css because it appears in neither the style-src directive nor the default-src directive of the Content Security Policy.
[Error] Refused to load webkit-pdfjs-viewer://pdfjs/extras/content-script.js because it appears in neither the script-src directive nor the default-src directive of the Content Security Policy.

We should exempt our own internal webkit-pdfjs-viewer URI scheme from CSP checks. It's an implementation detail of the website. We actually added new public WPE/GTK port API to allow Epiphany to do this, webkit_web_view_set_cors_allowlist(), (which is suddenly longer needed now that we've moved PDF.js to WebKit).
Comment 1 Michael Catanzaro 2022-07-28 16:45:52 PDT
(In reply to Michael Catanzaro from comment #0)
> It's an implementation detail of the website.

I meant to write: it's an implementation detail of WebKit, not something that the website could be expected to know about.
Comment 2 Michael Catanzaro 2022-08-01 14:07:00 PDT
Patrick says we need to call LegacySchemeRegistry::schemeShouldBypassContentSecurityPolicy from somewhere. Not clear where would be the nicest place to do this, since it only needs to happen once, not once for each PDFDocument.
Comment 3 Michael Catanzaro 2022-08-01 14:08:06 PDT
(In reply to Michael Catanzaro from comment #2)
> Patrick says we need to call
> LegacySchemeRegistry::schemeShouldBypassContentSecurityPolicy from
> somewhere. Not clear where would be the nicest place to do this, since it
> only needs to happen once, not once for each PDFDocument.

Well that was a dumb question. We should do it wherever we register the scheme.
Comment 4 Michael Catanzaro 2022-08-01 14:38:49 PDT
(In reply to Michael Catanzaro from comment #3)
> Well that was a dumb question. We should do it wherever we register the
> scheme.

Well it's more complicated than this. The scheme is never actually explicitly registered anywhere. It's just hardcoded into LegacySchemeRegistry.cpp.
Comment 5 Radar WebKit Bug Importer 2022-08-01 14:55:24 PDT
<rdar://problem/97938315>
Comment 6 Patrick Griffis 2022-08-01 15:04:51 PDT
Pull request: https://github.com/WebKit/WebKit/pull/2922
Comment 7 EWS 2022-08-02 10:09:04 PDT
Committed 253040@main (e9c47d55c988): <https://commits.webkit.org/253040@main>

Reviewed commits have been landed. Closing PR #2922 and removing active labels.