Pdf.js: Violações de CSP para inseguros inline em [email protected]

A política é violada por esta linha em v2.2.228 Function ("r", "regeneratorRuntime = r") (tempo de execução);

Na verdade, esse código não se origina em qualquer lugar da biblioteca PDF.js, mas sim de um polyfill Babel necessário para oferecer suporte a async / await em um navegador mais antigo. Como tal, infelizmente não está claro o que (se algo) pode ser feito sobre isso aqui .

Sim, acho que isso deve ser relatado no upstream.

O código
@Snuffleupagus Alguma dica sobre qual arquivo olhar?

Olhei mais fundo nisso. Sem chance :-(

Aqui está o problema regenerator-runtime / runtime.js .

O mesmo problema aqui.

@Snuffleupagus é possível distribuir 2 arquivos separados um para o navegador mais antigo e um segundo para os navegadores perenes?

Existe algum problema de upstream para rastrear? Enfrentando o mesmo problema atualmente

Você pode relatar o problema para https://github.com/facebook/regenerator. Parece que eles corrigiram algumas violações de CSP lá antes, então talvez eles estejam dispostos a corrigir isso também. Se eles consertarem no upstream, podemos atualizar a versão que usamos para consertar do nosso lado também.

Parece que os autores do pdf.js corrigiram esse problema aqui

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

mas devido a problemas no babel, eles tiveram que revertê-lo

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

Parece que temos um impasse aqui. Vejo três soluções aqui:

• Espere até que facebook/regenerator corrija os problemas.
  Pode ser o mais claro, mas muitos usuários preferem uma versão antiga do pdf.js
• Downgrade facebook/regenerator (talvez o babel tenha que ser rebaixado também)
• Fornece, além do ES5 atual, uma versão perene (ES2016 +) do pdf.js que não precisa de facebook/regenerator . (Muitos aplicativos da web atuais não precisam ser compatíveis com ES5).

De qualquer forma, a violação do CSP está bem documentada aqui
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);

Isso significa que, se você tiver uma violação de CSP, não deve executá-lo no modo estrito. Como esse é um comportamento conhecido no regenerator-runtime, o pdf.js deve desligar o modo estrito.

@timvandermeij Você pode reler o comentário, por favor, se há uma tarefa para fazer para pdf.js ou não?

Eu realmente não vejo o que o PDF.js poderia fazer de diferente aqui. Mesmo que o comentário seja claro, executamos intencionalmente o PDF.js no modo estrito para evitar erros e permitir otimizações. Dado que isso não aconteceu antes e nós nem mesmo usamos facebook/regenerator diretamente (mas apenas como uma dependência de outro pacote), eu diria que eles devem ser corrigidos, a menos que haja uma mudança trivial que possamos / precisamos fazer do nosso lado, mas não sei o que seria então ...

@timvandermeij

Obrigado por descobrir isso.

Que tal uma versão gratuita do babel do pdf.js? O navegador moderno não deve precisar de polyfill regenerator-runtime.

@jkroepke Idealmente, não

Estou tendo o mesmo problema com 2.3.200. Alguma solução alternativa ou correção? Obrigado.

@timvandermeij

No final, vejo que o pdf.js está fazendo errado, pois usa o modo estrito, que não é suportado ao usar regenerator-runtime / babel. Portanto, não é mais um problema de upstream porque as limitações estão bem documentadas.

Vejo 4 alternativas para resolver esses problemas:

• Usando uma versão mais antiga do babel. A versão 2.1.266 do pdf.js não tem esse problema. fixar as versões deve ser resolvê-lo. Isso deve ser o mais rápido.
• Não use o modo estrito, pois as dependências do babel não o suportam.
• Desligue os plugins transpile usando regenerator-runtime. (https://caniuse.com/#feat=es6-generators)
• Fornece duas versões do pdfjs-dist. Um para navegadores antigos (transpilado para ES5) e um para os navegadores atuais. (transpilar para ES6)

Usando uma versão mais antiga do babel. A versão 2.1.266 do pdf.js não tem esse problema. fixar as versões deve ser resolvê-lo. Isso deve ser o mais rápido.

Fixar uma dependência em uma versão antiga nunca é uma boa ideia, já que pode causar problemas se houver algum bug de segurança em versões mais antigas do Babel. Além disso, o uso de versões mais antigas de uma dependência pode prevenir, atrasar e / ou complicar a atualização de outras dependências causando, assim, outros problemas.

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

Apenas para esclarecer: Observe que a biblioteca PDF.js não está (atualmente) usando nenhuma função geradora, entretanto async / await está sendo usado e é por isso que esta dependência específica existe aqui.

Fornece duas versões do pdfjs-dist. Um para navegadores antigos (transpilado para ES5) e um para os navegadores atuais. (transpilar para ES6)

Esta parece ser a opção mais realista dentre as sugestões acima, mas como / quando isso acontecerá não está claro neste momento (observe a discussão / problemas em PR # 11241).
No entanto, observe que apenas os seguintes tipos (gerais) de compilações seriam fornecidos:

• Compilações compatíveis apenas com a versão mais recente do ES- {versão}, o que quer que seja no momento, ou seja, os arquivos compilados não são executados pelo Babel e nenhum polyfills são incluídos.
• Compilações compatíveis com ES5, ou seja, os arquivos compilados são analisados ​​pelo Babel e com polyfills incluídos.

Compilações apenas compatíveis com o ES- {versão} mais recente

Você respeitaria usar apenas funções / tecnologias suportadas pelas duas versões principais de navegador mais recentes?

Uma versão com funções de propostas de linguagem extremamente inovadoras que não são suportadas por um navegador mais recente não nos ajudaria.

Você respeitaria usar apenas funções / tecnologias suportadas pelas duas versões principais de navegador mais recentes?

Isso exigiria a produção de três tipos diferentes de builds, o que não parece uma boa ideia. Por um lado, os usuários provavelmente ficariam ainda mais confusos sobre qual build usar (já que imagino que os usuários não tenham certeza mesmo com apenas dois tipos de build). Além disso, a tentativa de fornecer várias compilações também colocará mais pressão, por exemplo, em relação ao suporte e à manutenção, para os poucos contribuidores regulares de PDF.js.

Basicamente, a situação desejável neste caso, no que me diz respeito, seria que um usuário de biblioteca:

• Escolhe a versão mais recente do ES e fornece polyfills conforme necessário com base em quais plataformas / navegadores eles precisam oferecer suporte.
• Escolhe a compilação ES5 e obtém todos os polyfills necessários incluídos e o código compatível com "todos" os navegadores modernos.

Uma versão com funções de propostas de linguagem extremamente inovadoras que não são suportadas por um navegador mais recente não nos ajudaria.

Falando historicamente, acho que nunca começamos a usar a funcionalidade imediatamente quando ela se tornou disponível, por exemplo, no Firefox Nightly, portanto, não posso prever que isso seja realmente um problema na prática.

Oi,

Eu encontrei o mesmo problema, a solução que usei foi carregar o regenerator-runtime através do meu polyfill diretamente.

Dessa forma, eu não alterei o pdfjs-dist. Isso me permitiu resolver meus problemas de CSP sem ter que recompilar pdfjs :)

@makidelille Você usa angular?

@makidelille Você usa angular?

usamos angularjs ( ainda ).

Para ser exato, construímos um visualizador personalizado em cima do pdf.js que é usado por meio de uma diretiva angularjs

editar: o visualizador personalizado é construído com angularjs de texto datilografado, é por isso que temos polyfills.

Estou recebendo outro erro inseguro-in-line para o CSS, a partir desta linha de código:
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.

Oi,

Eu encontrei o mesmo problema, a solução que usei foi carregar o regenerator-runtime através do meu polyfill diretamente.

Dessa forma, eu não alterei o pdfjs-dist. Isso me permitiu resolver meus problemas de CSP sem ter que recompilar pdfjs :)

Você (ou qualquer outra pessoa) sabe como essa solução se traduziria em angular 2+? É possível consertar isso?

Estou usando esta biblioteca e encontrando o mesmo problema de CSP (se você quiser, pode ver meu tíquete na lista de problemas de projetos), mas esses tipos de problemas com pacotes / npm / tipo de dependência não é algo que compreendo. Nós vamos.

Infelizmente, a versão antiga do pdfjs que não tinha esse problema (2.1.266, como mencionado acima) não parece ser compatível com esta biblioteca de wrapper angular 2+ e não parece ter uma versão que usasse essa versão do pdfjs internamente.

editar: Para qualquer pessoa em uma situação semelhante à minha, há outra biblioteca de wrapper pdfjs angular que funcionou para mim sem problemas de CSP. Veja aqui .

Acredito que esse problema pode ser resolvido agora, já que a próxima versão contará com dois tipos de compilações:

• Uma construção moderna (para navegadores atualizados), que não é transpilada com Babel e sem quaisquer polyfills incluídos.
• Uma compilação compatível com ES5 (pode ser usada, por exemplo, com IE11), que é transpilada com Babel e inclui todos os polyfills necessários.

Soa bem! Obrigado @Snuffleupagus e todos trabalharam nisso: 1st_place_medal: