Pdf.js: [email protected] . में असुरक्षित-इनलाइन के लिए सीएसपी उल्लंघन

इस लाइन द्वारा v2.2.228 Function("r", "regeneratorRuntime = r")(runtime);

यह वास्तव में PDF.js लाइब्रेरी के भीतर कहीं से भी उत्पन्न होने वाला कोड नहीं है, बल्कि यह पुराने ब्राउज़र में async / await का समर्थन करने के लिए आवश्यक बैबेल पॉलीफ़िल से आता है। इस प्रकार, यह दुर्भाग्य नहीं सभी स्पष्ट क्या (कुछ भी हो) पर इसके बारे में यहाँ किया जा सकता है है।

हां, मुझे लगता है कि इसके बजाय इसे अपस्ट्रीम में रिपोर्ट किया जाना चाहिए।

@timvandermeij कोड
@Snuffleupagus whta फ़ाइल पर कोई संकेत देखने के लिए?

इसमें गहराई से देखा। सवाल ही नहीं :-(

यहाँ समस्या regenerator-runtime/runtime.js है ।

यहाँ वही मुद्दा।

@Snuffleupagus पुराने ब्राउज़र के लिए 2 अलग-अलग फ़ाइलों को एक सदाबहार ब्राउज़र के लिए दूसरा वितरित करना संभव है?

क्या ट्रैक करने के लिए अपस्ट्रीम में कोई समस्या है? वर्तमान में एक ही समस्या का सामना करना पड़ रहा है

आप समस्या की रिपोर्ट https://github.com/facebook/regenerator पर कर सकते हैं

ऐसा लगता है कि pdf.js के लेखकों ने इस समस्या को यहाँ ठीक कर दिया है

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

लेकिन बेबेल पर मुद्दों के कारण उन्हें इसे वापस लेना पड़ा

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

ऐसा लगता है कि हमारे यहां गतिरोध है। मैं यहां तीन समाधान देखता हूं:

• facebook/regenerator समस्याओं के समाधान होने तक प्रतीक्षा करें।
  यह सबसे स्पष्ट हो सकता है लेकिन बहुत सारे उपयोगकर्ता pdf.js के पुराने संस्करण से चिपके रहेंगे
• डाउनग्रेड facebook/regenerator (हो सकता है कि बेबेल को भी डाउनग्रेड करना पड़े)
• वर्तमान ES5 के अलावा pdf.js का एक सदाबहार (ES2016+) संस्करण प्रदान करें, जिसकी आवश्यकता नहीं है facebook/regenerator । (बहुत से मौजूदा वेब एप्लिकेशन को ES5 के अनुरूप होने की आवश्यकता नहीं थी)।

वैसे भी सीएसपी उल्लंघन यहाँ अच्छी तरह से प्रलेखित है
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);

इसका मतलब है, अगर आपके पास सीएसपी उल्लंघन है तो आपको इसे सख्त मोड में नहीं चलाना चाहिए। चूंकि यह पुनर्योजी-रनटाइम में एक ज्ञात व्यवहार है, इसलिए pdf.js को सख्त-मोड को बंद करना चाहिए।

@timvandermeij क्या आप कृपया टिप्पणी को फिर से पढ़ सकते हैं यदि pdf.js के लिए कोई कार्य है या नहीं?

मैं वास्तव में नहीं देखता कि PDF.js यहाँ अलग तरीके से क्या कर सकता है। हालांकि टिप्पणी स्पष्ट है, हम त्रुटियों को रोकने और अनुकूलन की अनुमति देने के लिए जानबूझकर PDF.js को सख्त मोड के साथ चलाते हैं। यह देखते हुए कि यह पहले नहीं हुआ था और हम सीधे facebook/regenerator उपयोग भी नहीं करते हैं (लेकिन केवल किसी अन्य पैकेज की निर्भरता के रूप में) मैं कहूंगा कि उन्हें पैच किया जाना चाहिए, जब तक कि कोई मामूली परिवर्तन न हो/ हमारी तरफ से करने की जरूरत है, लेकिन मुझे नहीं पता कि वह तब क्या होगा...

@timvandermeij

इसका पता लगाने के लिए धन्यवाद।

pdf.js के बेबेल मुक्त संस्करण के बारे में क्या? आधुनिक ब्राउजर को रीजेनरेटर-रनटाइम पॉलीफिल की आवश्यकता नहीं होनी चाहिए।

@jkroepke आदर्श रूप से हम बैबेल का बिल्कुल भी उपयोग नहीं करेंगे, लेकिन दुर्भाग्य से अभी के लिए PDF.js के लिए उन सभी ब्राउज़रों में काम करना आवश्यक है जिनका हम समर्थन करते हैं, इसलिए इससे छुटकारा पाना कुछ ऐसा नहीं है जिस पर हम अभी विचार कर सकते हैं। बेशक आप स्वयं PDF.js बना सकते हैं और Babel transpiling को अक्षम कर सकते हैं।

मैं 2.3.200 के साथ एक ही समस्या का सामना कर रहा हूँ। कोई कामकाज या सुधार? धन्यवाद।

@timvandermeij

अंत में, मैं देखता हूं कि pdf.js इसे गलत कर रहा है क्योंकि यह सख्त मोड का उपयोग करता है जो रीजेनरेटर-रनटाइम/बेबेल का उपयोग करते समय समर्थित नहीं है। इसलिए यह अब अपस्ट्रीम समस्या नहीं है क्योंकि सीमाएं अच्छी तरह से प्रलेखित हैं।

मैं इस मुद्दे को हल करने के लिए 4 विकल्प देखता हूं:

• बेबेल के पुराने संस्करण का उपयोग करना। pdf.js के 2.1.266 संस्करण में यह समस्या नहीं है। संस्करणों को पिन करना इसे हल करना चाहिए। यह सबसे तेज होना चाहिए।
• सख्त मोड का उपयोग न करें क्योंकि बेबेल की निर्भरता इसका समर्थन नहीं करती है।
• पुनर्योजी-रनटाइम का उपयोग करके ट्रांसपाइल प्लगइन्स को बंद करें। (https://caniuse.com/#feat=es6-generators)
• pdfjs-dist के दो संस्करण प्रदान करें। एक पुराने ब्राउज़र के लिए (ES5 में स्थानांतरित) और एक वर्तमान ब्राउज़र के लिए। (ES6 के लिए पारदर्शी)

बेबेल के पुराने संस्करण का उपयोग करना। pdf.js के 2.1.266 संस्करण में यह समस्या नहीं है। संस्करणों को पिन करना इसे हल करना चाहिए। यह सबसे तेज होना चाहिए।

पुराने संस्करण पर निर्भरता को पिन करना कभी भी एक अच्छा विचार नहीं है, क्योंकि पुराने बैबल संस्करणों में कोई सुरक्षा बग होने पर यह समस्या पैदा कर सकता है। इसके अलावा, एक निर्भरता के पुराने संस्करणों का उपयोग करने से अन्य निर्भरताओं के अद्यतन को रोका जा सकता है, देरी हो सकती है और/या जटिल हो सकती है जिससे अन्य समस्याएं हो सकती हैं।

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

बस स्पष्ट करने के लिए: कृपया ध्यान दें कि PDF.js लाइब्रेरी (वर्तमान में) किसी जनरेटर फ़ंक्शन का उपयोग नहीं कर रही है, हालांकि async / await का उपयोग किया जा रहा है और इसलिए यह विशेष निर्भरता यहां मौजूद है।

pdfjs-dist के दो संस्करण प्रदान करें। एक पुराने ब्राउज़र के लिए (ES5 में स्थानांतरित) और एक वर्तमान ब्राउज़र के लिए। (ES6 के लिए पारदर्शी)

यह उपरोक्त सुझावों में से सबसे यथार्थवादी विकल्प की तरह लगता है, लेकिन यह कैसे/कब होगा यह इस समय स्पष्ट नहीं है (पीआर #११२४१ में चर्चा/समस्याओं पर ध्यान दें)।
हालांकि, ध्यान दें कि तब केवल निम्नलिखित (सामान्य) प्रकार के बिल्ड प्रदान किए जाएंगे:

• केवल नवीनतम ES-{संस्करण} के साथ संगत बनाता है, उस समय जो कुछ भी हो सकता है, अर्थात निर्मित फ़ाइलें बैबेल के माध्यम से नहीं चलती हैं और कोई पॉलीफ़िल शामिल
• बिल्ड जो ES5-संगत हैं, यानी निर्मित फाइलें बैबेल द्वारा पार्स की जाती हैं और पॉलीफिल शामिल हैं।

केवल नवीनतम ES-{संस्करण} के साथ संगत बनाता है

क्या आप केवल नवीनतम 2 प्रमुख ब्राउज़र संस्करणों द्वारा समर्थित कार्यों/प्रौद्योगिकियों का उपयोग करने का सम्मान करेंगे?

सुपर ब्लीडिंग एज भाषा प्रस्तावों वाला एक संस्करण जो नए ब्राउज़र द्वारा समर्थित नहीं है, हमारी मदद नहीं करेगा।

क्या आप केवल नवीनतम 2 प्रमुख ब्राउज़र संस्करणों द्वारा समर्थित कार्यों/प्रौद्योगिकियों का उपयोग करने का सम्मान करेंगे?

इसके लिए तीन अलग-अलग प्रकार के निर्माण की आवश्यकता होगी, जो एक अच्छा विचार नहीं लगता है। एक के लिए, उपयोगकर्ता शायद और भी भ्रमित होंगे कि किस निर्माण का उपयोग करना है (क्योंकि मुझे लगता है कि उपयोगकर्ता केवल दो प्रकार के निर्माण के साथ भी अनिश्चित हैं)। इसके अलावा, कई बिल्ड प्रदान करने का प्रयास भी कुछ नियमित PDF.js योगदानकर्ताओं पर अधिक दबाव डालेगा, उदाहरण के लिए समर्थन और रखरखाव दोनों से संबंधित।

मूल रूप से, जहां तक ​​मेरा संबंध है इस मामले में वांछनीय स्थिति यह होगी कि एक पुस्तकालय उपयोगकर्ता या तो:

• ES-नवीनतम बिल्ड को चुनता है, और आवश्यकतानुसार स्वयं पॉलीफ़िल प्रदान करता है जिसके आधार पर उन्हें समर्थन करने के लिए प्लेटफ़ॉर्म/ब्राउज़र की आवश्यकता होती है।
• ES5 बिल्ड को चुनता है, और सभी आवश्यक पॉलीफ़िल शामिल करता है और "सभी" आधुनिक ब्राउज़रों के साथ संगत कोड प्राप्त करता है।

सुपर ब्लीडिंग एज भाषा प्रस्तावों वाला एक संस्करण जो नए ब्राउज़र द्वारा समर्थित नहीं है, हमारी मदद नहीं करेगा।

ऐतिहासिक रूप से मुझे नहीं लगता कि हमने कभी भी कार्यक्षमता का उपयोग तुरंत शुरू किया है जब यह उपलब्ध हो गया है जैसे फ़ायरफ़ॉक्स नाइटली, इसलिए मैं यह नहीं देख सकता कि यह वास्तव में व्यवहार में एक समस्या है।

नमस्ते,

मैं उसी मुद्दे में भाग गया, मैंने जिस समाधान का उपयोग किया वह रीजनरेटर -रनटाइम लोड करना था, सीधे मेरे पॉलीफिल को सोचा।

इस तरह मैंने pdfjs-dist. इसने मुझे पीडीएफजे को पुन: संकलित किए बिना मेरे सीएसपी मुद्दों को हल करने की इजाजत दी :)

@makidelille क्या आप कोणीय का उपयोग करते हैं?

@makidelille क्या आप कोणीय का उपयोग करते हैं?

हम कोणीयज ( अभी भी ) का उपयोग करते हैं।

सटीक होने के लिए, हमने pdf.js के शीर्ष पर एक कस्टम व्यूअर बनाया है जिसका उपयोग angularjs निर्देश के माध्यम से किया जाता है

संपादित करें: कस्टम व्यूअर टाइपस्क्रिप्ट angularjs के साथ बनाया गया है, इसलिए हमारे पास पॉलीफिल हैं।

मुझे कोड की इस पंक्ति से सीएसएस के लिए एक और असुरक्षित-इनलाइन त्रुटि मिल रही है:
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.

नमस्ते,

मैं उसी मुद्दे में भाग गया, मैंने जिस समाधान का उपयोग किया वह रीजनरेटर -रनटाइम लोड करना था, सीधे मेरे पॉलीफिल को सोचा।

इस तरह मैंने pdfjs-dist. इसने मुझे पीडीएफजे को पुन: संकलित किए बिना मेरे सीएसपी मुद्दों को हल करने की इजाजत दी :)

क्या आप (या कोई और) जानते हैं कि यह समाधान कोणीय 2+ में कैसे अनुवाद करेगा? क्या इसे ठीक करना संभव है?

मैं इस पुस्तकालय का उपयोग कर रहा हूं और उसी सीएसपी समस्या में चल रहा हूं (यदि आप चाहते हैं कि आप उस परियोजना के मुद्दों की सूची में मेरा टिकट देख सकते हैं), लेकिन पैकेज/एनपीएम/निर्भरता प्रकार की सामग्री के साथ इस प्रकार की समस्याएं कुछ ऐसी नहीं हैं जिन्हें मैं समझता हूं वह सब कुंआ।

दुर्भाग्य से पीडीएफजे का पुराना संस्करण जिसमें यह समस्या नहीं थी (२.१.२६६, जैसा कि ऊपर बताया गया है) इस कोणीय २+ रैपर पुस्तकालय के साथ संगत नहीं लगता है, और ऐसा प्रतीत नहीं होता है कि पीडीएफजे के उस संस्करण का उपयोग करने वाला संस्करण है आंतरिक रूप से।

संपादित करें: मेरे जैसी ही स्थिति में किसी के लिए, एक और कोणीय पीडीएफजेएस रैपर लाइब्रेरी है जो मेरे लिए बिना किसी सीएसपी मुद्दों के काम करती है। यहां देखें।

मेरा मानना ​​है कि इस मुद्दे को अब बंद किया जा सकता है, क्योंकि आगामी रिलीज में दो प्रकार के बिल्ड होंगे:

• एक आधुनिक बिल्ड (अप-टू-डेट ब्राउज़रों के लिए), जिसे बैबेल के साथ ट्रांसपाइल नहीं किया गया है और बिना किसी पॉलीफ़िल के शामिल किया गया है।
• एक ES5-संगत बिल्ड (उदाहरण के लिए IE11 के साथ उपयोग किया जा सकता है), जिसे बैबेल के साथ ट्रांसपिल्ड किया गया है और इसमें सभी आवश्यक पॉलीफ़िल शामिल हैं।

बढ़िया है! धन्यवाद @Snuffleupagus और सभी ने इस पर काम किया: 1st_place_medal: