Pdf.js: Pelanggaran CSP untuk unsafe-inline di [email protected]

Kebijakan ini dilanggar oleh baris ini di v2.2.228 Function("r", "regeneratorRuntime = r")(runtime);

Itu sebenarnya bukan kode yang berasal dari mana pun di dalam pustaka PDF.js itu sendiri, melainkan berasal dari polyfill Babel yang diperlukan untuk mendukung async / await di browser lama. Karena itu, sayangnya sama sekali tidak jelas apa (jika ada) yang bisa dilakukan di sini .

Ya, saya pikir ini harus dilaporkan ke hulu.

@timvandermeij Kode dalam pdf.js dapat ditulis sehingga polyfill tidak diperlukan.
@Snuffleupagus Ada petunjuk tentang file apa yang harus dilihat?

Melihat lebih dalam ke dalamnya. Tidak ada kesempatan :-(

Inilah masalahnya regenerator-runtime/runtime.js .

Masalah yang sama di sini.

@Snuffleupagus apakah mungkin untuk mendistribusikan 2 file terpisah satu untuk browser lama dan kedua untuk browser evergreen?

Apakah ada masalah di hulu untuk dilacak? Menghadapi masalah yang sama saat ini

Anda dapat melaporkan masalah ini ke https://github.com/facebook/regenerator. Sepertinya mereka telah memperbaiki beberapa pelanggaran CSP di sana sebelumnya, jadi mungkin mereka juga ingin memperbaiki yang ini. Jika mereka memperbaikinya di hulu, kami juga dapat memperbarui versi yang kami gunakan untuk memperbaikinya di pihak kami.

Sepertinya penulis pdf.js memperbaiki masalah ini di sini

https://github.com/facebook/regenerator/pull/353

tetapi karena masalah pada babel mereka harus mengembalikannya

https://github.com/facebook/regenerator/pull/369

Sepertinya kita menemui jalan buntu di sini. Saya melihat tiga solusi di sini:

• Tunggu hingga facebook/regenerator memperbaiki masalah.
  Ini mungkin yang paling jelas tetapi banyak pengguna akan tetap menggunakan pdf.js versi lama
• Downgrade facebook/regenerator (mungkin babel juga harus diturunkan)
• Berikan selain ES5 saat ini versi pdf.js yang selalu hijau (ES2016+) yang tidak memerlukan facebook/regenerator . (Banyak aplikasi web saat ini tidak harus sesuai dengan ES5).

Pokoknya pelanggaran CSP didokumentasikan dengan baik di sini
https://github.com/facebook/regenerator/blob/6e9e8d7747c2ab49927bdd9dd6261753181faec1/packages/regenerator-runtime/runtime.js#L716 -L725

  // This module should not be running in strict mode, so the above
  // assignment should always work unless something is misconfigured. Just
  // in case runtime.js accidentally runs in strict mode, we can escape
  // strict mode using a global Function call. This could conceivably fail
  // if a Content Security Policy forbids using Function, but in that case
  // the proper solution is to fix the accidental strict mode problem. If
  // you've misconfigured your bundler to force strict mode and applied a
  // CSP to forbid Function, and you're not willing to fix either of those
  // problems, please detail your unique predicament in a GitHub issue.
  Function("r", "regeneratorRuntime = r")(runtime);

Artinya, jika Anda memiliki pelanggaran CSP, Anda tidak boleh menjalankannya dalam mode ketat. Karena ini adalah perilaku yang diketahui dalam waktu proses regenerator, kebutuhan pdf.js harus mematikan mode ketat.

@timvandermeij Bisakah Anda membaca kembali komentar jika ada tugas yang harus dilakukan untuk pdf.js atau tidak?

Saya tidak benar-benar melihat apa yang bisa dilakukan PDF.js secara berbeda di sini. Meskipun komentarnya jelas, kami sengaja menjalankan PDF.js dengan mode ketat untuk mencegah kesalahan dan memungkinkan pengoptimalan. Mengingat ini tidak terjadi sebelumnya dan kami bahkan tidak menggunakan facebook/regenerator secara langsung (tetapi hanya sebagai ketergantungan paket lain) saya akan mengatakan bahwa itu harus ditambal, kecuali ada perubahan sepele yang kami dapat/ perlu dilakukan di pihak kita, tetapi saya tidak tahu apa yang akan terjadi kemudian ...

@timvandermeij

Terima kasih untuk mengetahuinya.

Bagaimana dengan pdf.js versi gratis babel? Peramban modern seharusnya tidak memerlukan polyfill regenerator-runtime.

@jkroepke Idealnya kami tidak akan menggunakan Babel sama sekali, tetapi sayangnya untuk saat ini PDF.js diperlukan untuk bekerja di semua browser yang kami dukung, jadi menghapusnya bukanlah sesuatu yang dapat kami pertimbangkan saat ini. Tentu saja Anda dapat membuat PDF.js sendiri dan menonaktifkan transpiling Babel.

Saya mengalami masalah yang sama dengan 2.3.200. Ada solusi atau perbaikan? Terima kasih.

@timvandermeij

Pada akhirnya, saya melihat bahwa pdf.js melakukan kesalahan karena menggunakan mode ketat yang tidak didukung saat menggunakan regenerator-runtime/babel. Jadi bukan masalah hulu lagi karena batasannya terdokumentasi dengan baik.

Saya melihat 4 alternatif untuk menyelesaikan masalah ini:

• Menggunakan versi babel yang lebih lama. Versi 2.1.266 pdf.js tidak memiliki masalah ini. menyematkan versi harus menyelesaikannya. Ini harus menjadi yang tercepat.
• Jangan gunakan mode ketat karena dependensi babel tidak mendukungnya.
• Matikan plugin transpile dengan menggunakan regenerator-runtime. (https://caniuse.com/#feat=es6-generators)
• Berikan dua versi pdfjs-dist. Satu untuk browser lama (diterjemahkan ke ES5) dan satu untuk browser saat ini. (transpile ke ES6)

Menggunakan versi babel yang lebih lama. Versi 2.1.266 pdf.js tidak memiliki masalah ini. menyematkan versi harus menyelesaikannya. Ini harus menjadi yang tercepat.

Menjepit ketergantungan ke versi lama tidak pernah merupakan ide yang baik, karena untuk satu dapat menyebabkan masalah jika ada bug keamanan dalam versi Babel tua. Lebih jauh lagi, menggunakan versi lama dari satu dependensi dapat mencegah, menunda, dan/atau mempersulit pembaruan dependensi lain sehingga menyebabkan masalah lain.

[...] (https://caniuse.com/#feat=es6-generators)

Hanya untuk memperjelas: Harap dicatat bahwa perpustakaan PDF.js tidak (saat ini) menggunakan fungsi generator apa pun, namun async / await sedang digunakan dan itulah mengapa ketergantungan khusus ini ada di sini.

Berikan dua versi pdfjs-dist. Satu untuk browser lama (diterjemahkan ke ES5) dan satu untuk browser saat ini. (transpile ke ES6)

Ini sepertinya opsi yang paling realistis dari saran di atas, tetapi bagaimana/kapan itu akan terjadi tidak jelas pada saat ini (perhatikan diskusi/masalah di PR #11241).
Namun, perhatikan bahwa hanya jenis bangunan (umum) berikut yang akan disediakan:

• Membangun hanya kompatibel dengan terbaru es- {version}, apa pun yang mungkin pada saat itu, yaitu file yang dibangun tidak dijalankan melalui Babel dan tidak ada polyfills disertakan.
• Build yang kompatibel dengan ES5, yaitu file yang dibangun diurai oleh Babel dan disertakan dengan polyfill.

Build hanya kompatibel dengan ES-{version} terbaru

Apakah Anda menghormati untuk hanya menggunakan fungsi/teknologi yang didukung oleh 2 versi browser utama terbaru?

Versi dengan fungsi proposal bahasa yang sangat berdarah yang tidak didukung oleh browser yang lebih baru tidak akan membantu kami.

Apakah Anda menghormati untuk hanya menggunakan fungsi/teknologi yang didukung oleh 2 versi browser utama terbaru?

Itu akan membutuhkan produksi tiga jenis bangunan yang berbeda, yang sepertinya bukan ide yang bagus. Pertama, pengguna mungkin akan lebih bingung lagi build mana yang akan digunakan (karena saya membayangkan pengguna tidak yakin bahkan hanya dengan dua jenis build). Lebih jauh lagi, mencoba menyediakan beberapa build juga akan lebih membebani, misalnya terkait dengan dukungan dan pemeliharaan, pada beberapa kontributor PDF.js reguler.

Pada dasarnya, situasi yang diinginkan dalam kasus ini sejauh yang saya ketahui adalah bahwa pengguna perpustakaan:

• Memilih build terbaru ES, dan menyediakan sendiri polyfill seperlunya berdasarkan platform/browser mana yang perlu mereka dukung.
• Memilih build ES5, dan mendapatkan semua polyfill yang diperlukan disertakan dan kode yang kompatibel dengan "semua" browser modern.

Versi dengan fungsi proposal bahasa yang sangat berdarah yang tidak didukung oleh browser yang lebih baru tidak akan membantu kami.

Secara historis saya tidak berpikir bahwa kita pernah mulai menggunakan fungsionalitas segera ketika tersedia di misalnya Firefox Nightly, maka saya tidak dapat melihat ini benar-benar menjadi banyak masalah dalam praktek.

Hai,

Saya mengalami masalah yang sama, solusi yang saya gunakan adalah memuat regenerator-runtime berpikir polyfill saya secara langsung.

Dengan cara ini saya tidak mengubah pdfjs-dist. Itu memungkinkan saya untuk menyelesaikan masalah CSP saya tanpa harus mengkompilasi ulang pdfjs :)

@makidelille Apakah Anda menggunakan sudut?

@makidelille Apakah Anda menggunakan sudut?

kami menggunakan angularjs ( masih ).

Tepatnya, kami telah membangun penampil khusus di atas pdf.js yang digunakan melalui arahan angularjs

edit: penampil khusus dibuat dengan TypeScript angularjs, itu sebabnya kami memiliki polyfill.

Saya mendapatkan kesalahan inline tidak aman lainnya untuk CSS, dari baris kode ini:
https://github.com/mozilla/pdf.js/blob/master/web/ui_utils.js#L893

Refused to apply inline style because it violates the following Content Security Policy directive: "style-src ...". Either the 'unsafe-inline' keyword, a hash ('sha256-MW4Iy/yu3WipUpTMM/T6OjvUu9R6vUwutodlmYNo6qM='), or a nonce ('nonce-...') is required to enable inline execution.

Hai,

Saya mengalami masalah yang sama, solusi yang saya gunakan adalah memuat regenerator-runtime berpikir polyfill saya secara langsung.

Dengan cara ini saya tidak mengubah pdfjs-dist. Itu memungkinkan saya untuk menyelesaikan masalah CSP saya tanpa harus mengkompilasi ulang pdfjs :)

Apakah Anda (atau siapa pun) tahu bagaimana solusi ini akan diterjemahkan ke angular 2+ ? Apakah mungkin untuk memperbaiki ini?

Saya menggunakan perpustakaan ini dan mengalami masalah CSP yang sama (jika Anda mau, Anda dapat melihat tiket saya di daftar masalah proyek itu), tetapi masalah semacam ini dengan paket/npm/jenis ketergantungan bukanlah sesuatu yang saya pahami semua itu dengan baik.

Sayangnya versi lama pdfjs yang tidak memiliki masalah ini (2.1.266, seperti yang disebutkan di atas) tampaknya tidak kompatibel dengan pustaka pembungkus sudut 2+ ini, dan tampaknya tidak memiliki versi yang menggunakan versi pdfjs tersebut secara internal.

sunting: Untuk siapa pun dalam situasi yang sama seperti saya, ada perpustakaan pembungkus pdfjs sudut lain yang berfungsi untuk saya tanpa masalah CSP. Lihat di sini .

Saya percaya bahwa masalah ini dapat diselesaikan sekarang, karena rilis yang akan

• Build modern (untuk browser terbaru), yang tidak ditranspilasikan dengan Babel dan tanpa polyfill yang disertakan.
• Sebuah build yang kompatibel dengan ES5 (dapat digunakan misalnya dengan IE11), yang ditranspilasikan dengan Babel dan mencakup semua polyfill yang diperlukan.

Kedengarannya bagus! Terima kasih @Snuffleupagus dan semua orang mengerjakan :1st_place_medal ini: