Pdf.js: Нарушения CSP из-за небезопасного встраивания в [email protected]

Политика нарушается этой строкой в v2.2.228 Function ("r", "refreshratorRuntime = r") (время выполнения);

На самом деле это не код, происходящий где-либо в самой библиотеке PDF.js, а скорее он исходит из полифила Babel, необходимого для поддержки async / await в более старом браузере. Таким образом, к сожалению, не совсем понятно, что (и если что) можно здесь сделать .

Да, я думаю, что об этом следует сообщить в апстриме.

@timvandermeij Код в pdf.js может быть написан так, что полифилл не нужен.
@Snuffleupagus Есть подсказки, на какой файл стоит посмотреть?

Посмотрел глубже. Без шансов :-(

Вот проблема- регенератор-runtime / runtime.js .

Здесь та же проблема.

@Snuffleupagus , можно ли раздавать 2 отдельных файла: один для старого браузера, второй для вечнозеленых браузеров?

Есть ли какие-то проблемы с апстримом, которые нужно отслеживать? Столкнувшись с той же проблемой в настоящее время

Вы можете сообщить о проблеме по адресу https://github.com/facebook/regenerator. Похоже, они исправляли некоторые нарушения CSP там раньше, так что, возможно, они тоже хотят исправить это. Если они исправят это в апстриме, мы сможем обновить версию, которую используем, чтобы исправить это и на нашей стороне.

Похоже, авторы pdf.js исправили эту проблему здесь

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

но из-за проблем с babel им пришлось откатить его

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

Похоже, у нас тут тупик. Я вижу здесь три решения:

• Подождите, пока facebook/regenerator устранит проблемы.
  Это может быть самым ясным, но многие пользователи будут придерживаться старой версии pdf.js.
• Перейти на более раннюю версию facebook/regenerator (возможно, версию Babel тоже нужно понизить)
• Предоставьте в дополнение к текущему ES5 вечнозеленую (ES2016 +) версию pdf.js, которая не требует facebook/regenerator . (Многие современные веб-приложения не обязательно должны быть совместимы с ES5).

В любом случае нарушение CSP хорошо задокументировано здесь
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);

Это означает, что если у вас есть нарушение CSP, вы не должны запускать это в строгом режиме. Поскольку это известное поведение во время выполнения регенератора, pdf.js необходимо отключить строгий режим.

@timvandermeij Не могли бы вы перечитать комментарий, есть ли задача для pdf.js или нет?

Я действительно не понимаю, что PDF.js может здесь делать по-другому. Несмотря на то, что комментарий ясен, мы намеренно запускаем PDF.js в строгом режиме, чтобы предотвратить ошибки и обеспечить оптимизацию. Учитывая, что этого не было раньше, и мы даже не используем facebook/regenerator напрямую (а только как зависимость от другого пакета), я бы сказал, что они должны быть исправлены, если нет тривиального изменения, которое мы можем / нужно делать на нашей стороне, но я не знаю, что это будет тогда ...

@timvandermeij

Спасибо, что разобрались.

А как насчет бесплатной версии pdf.js от babel? Современный браузер не нуждается в полифилле во время выполнения регенератора.

@jkroepke В идеале мы бы вообще не использовали Babel, но, к сожалению, сейчас он требуется для того, чтобы PDF.js работал во всех поддерживаемых нами браузерах, поэтому сейчас мы не можем обойтись без него. Конечно, вы можете создать PDF.js самостоятельно и отключить транспилирование Babel.

У меня такая же проблема с 2.3.200. Любое обходное решение или исправления? Спасибо.

@timvandermeij

В конце я вижу, что pdf.js делает это неправильно, поскольку он использует строгий режим, который не поддерживается при использовании регенератора-runtime / babel. Так что это больше не проблема апстрима, потому что ограничения хорошо задокументированы.

Я вижу 4 альтернативы решения этой проблемы:

• Используя старую версию babel. Версия pdf.js 2.1.266 не имеет этой проблемы. закрепление версий должно решить эту проблему. Это должно быть быстрее всего.
• Не используйте строгий режим, так как зависимости babel его не поддерживают.
• Отключите плагины транспиляции с использованием среды выполнения регенератора. (https://caniuse.com/#feat=es6-generators)
• Предоставьте две версии pdfjs-dist. Один для старых браузеров (перенесен на ES5) и один для текущих браузеров. (переносится на ES6)

Используя старую версию babel. Версия pdf.js 2.1.266 не имеет этой проблемы. закрепление версий должно решить эту проблему. Это должно быть быстрее всего.

Прикрепление зависимости к старой версии никогда не является хорошей идеей, так как это, например, может вызвать проблемы, если в старых версиях Babel есть какие-либо ошибки безопасности. Кроме того, использование более старых версий одной зависимости может предотвращать, задерживать и / или усложнять обновление других зависимостей, вызывая другие проблемы.

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

Просто для пояснения: обратите внимание, что библиотека PDF.js (в настоящее время) не использует никаких функций генератора, однако используется async / await , и поэтому здесь существует эта конкретная зависимость.

Предоставьте две версии pdfjs-dist. Один для старых браузеров (перенесен на ES5) и один для текущих браузеров. (переносится на ES6)

Это кажется наиболее реалистичным вариантом из предложенных выше, но как и когда это произойдет, пока не ясно (обратите внимание на обсуждение / проблемы в PR № 11241).
Однако обратите внимание, что тогда будут предоставлены только следующие (общие) типы сборок:

• Сборки совместимы только с последней версией ES- {version}, какой бы она ни была в то время, т.е. созданные файлы не запускаются через Babel и не включаются полифиллы.
• Сборки, совместимые с ES5, т.е. собранные файлы анализируются Babel и включают в себя полифиллы.

Сборки совместимы только с последней версией ES- {версия}

Вы бы согласились использовать только функции / технологии, поддерживаемые двумя последними основными версиями браузеров?

Версия с суперсовременными функциями языковых предложений, которые не поддерживаются новым браузером, нам не поможет.

Вы бы согласились использовать только функции / технологии, поддерживаемые двумя последними основными версиями браузеров?

Для этого потребуется создать три разных типа сборок, что не кажется хорошей идеей. Во-первых, пользователи, вероятно, будут еще больше сбиты с толку относительно того, какую сборку использовать (поскольку я полагаю, что пользователи не уверены даже в двух типах сборок). Более того, попытка предоставить несколько сборок также создаст дополнительную нагрузку, например, связанную как с поддержкой, так и с обслуживанием, для нескольких постоянных участников PDF.js.

По сути, желательной ситуацией в этом случае, насколько я понимаю, будет то, что пользователь библиотеки:

• Выбирает последнюю сборку ES и при необходимости предоставляет полифиллы в зависимости от того, какие платформы / браузеры они должны поддерживать.
• Выбирает сборку ES5 и получает все необходимые полифиллы и код, совместимый со «всеми» современными браузерами.

Версия с суперсовременными функциями языковых предложений, которые не поддерживаются новым браузером, нам не поможет.

С исторической точки зрения я не думаю, что мы когда-либо начинали использовать функциональность сразу же, как только она стала доступной, например, в Firefox Nightly, поэтому я не могу предвидеть, что это на самом деле станет большой проблемой на практике.

Привет,

Я столкнулся с той же проблемой, решение, которое я использовал, заключалось в том, чтобы загрузить регенераторную среду выполнения напрямую с моим полифилом.

Таким образом, я не менял pdfjs-dist. Это позволило мне решить мои проблемы с CSP без перекомпиляции pdfjs :)

@makidelille Вы используете angular?

@makidelille Вы используете angular?

мы используем angularjs ( все еще ).

Если быть точным, мы создали настраиваемую программу просмотра поверх pdf.js, которая используется с помощью директивы angularjs.

edit: пользовательский просмотрщик построен с использованием машинописного текста angularjs, поэтому у нас есть полифиллы.

Я получаю еще одну небезопасную встроенную ошибку для CSS из этой строки кода:
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. Это позволило мне решить мои проблемы с CSP без перекомпиляции pdfjs :)

Вы (или кто-либо еще) знаете, как это решение будет переведено на angular 2+? Можно ли это исправить?

Я использую эту библиотеку и сталкиваюсь с той же проблемой CSP (если вы хотите, чтобы вы могли видеть мой билет в этом списке проблем проектов), но такого рода проблемы с материалами типа packages / npm / dependency не являются чем-то, что я понимаю хорошо.

К сожалению, старая версия pdfjs, у которой не было этой проблемы (2.1.266, как упоминалось выше), похоже, не совместима с этой библиотекой оболочки angular 2+, и, похоже, не имеет версии, которая использовала эту версию pdfjs внутренне.

edit: Для всех, кто находится в подобной ситуации, как я, есть еще одна библиотека-оболочка angular pdfjs, которая работала для меня без проблем с CSP. Смотрите здесь .

Я считаю, что сейчас эту проблему можно закрыть, поскольку в предстоящем выпуске будут два вида сборок:

• Современная сборка (для современных браузеров), которая не транслируется с помощью Babel и без каких-либо включенных полифиллов.
• ES5-совместимая сборка (может использоваться, например, с IE11), которая передается с помощью Babel и включает все необходимые полифиллы.

Звучит отлично! Спасибо @Snuffleupagus, и все работали над этим: 1st_place_medal: