Pdf.js: Le viewer.js ne peut pas prendre de flux PDF en ligne

Les problèmes connexes sont #522, #586 et #842

Comme indiqué dans les problèmes ci-dessus, c'est quelque chose que l'utilisateur devra corriger lui-même à l'aide d'un proxy ou CORS.

Salut Brend,

quelle est la principale raison pour laquelle « l'utilisateur devra réparer lui-même à l'aide d'un proxy ou CORS » ?

Il est important que le PDF puisse provenir du serveur local (téléchargement), du serveur en tant que fichier, du serveur en tant que flux comme "http://".

En tant qu'URL d'image, le lecteur PDF doit prendre en charge l'URL HTTP.

Merci

@jonasyuandotcom le cors vous permet d'obtenir le pdf en utilisant http à partir du même serveur. cependant, le navigateur protège l'utilisateur contre l'obtention/l'envoi de données à des serveurs étrangers. Ces serveurs doivent utiliser des en-têtes http pour contourner cette restriction.

Étant donné que votre proxy côté serveur sera situé sur le même serveur qu'un spectateur, les cors seront d'accord avec cela.

@notmasteryet merci. Cela fonctionne lorsque vous utilisez le même serveur comme

var kDefaultURL = '/pdf-reader-web/sample.pdf';

Salut Jonas,

Nous ne l'implémenterons pas de notre côté car il ne nous est pas possible de l'implémenter en raison des restrictions de sécurité du navigateur. Voir http://en.wikipedia.org/wiki/XMLHttpRequest#Cross -domain_requests

Brendan

Salut @brendandahl

Je me demandais s'il y avait une mise à jour depuis 2011 ? Est-il toujours impossible de résoudre les problèmes CORS ?

Oui. Voir https://github.com/mozilla/pdf.js/wiki/Frequently-Asked-Questions#faq -xhr pour plus d'informations.

Merci Tim !

Salut @timvandermeij. Merci pour votre réponse. J'ai essayé de nombreuses solutions mais je ne suis toujours pas autorisé à autoriser CORS sur mon serveur Web. Avez-vous un exemple de git ?

@Dassine et voilà http://mozilla.github.io/pdf.js/web/viewer.html?file=//async5.org/moz/pdfjs.pdf -- PDF Viewer charge http://async5.org /moz/pdfjs.pdf . Notez qu'async5.org permet à mozilla.github.io d'obtenir des fichiers. Sinon, un navigateur Web doit bloquer l'accès à un fichier distant pour des raisons de sécurité. C'est une pratique courante sur le Web et PDF.js ne peut rien faire pour contourner la sécurité des navigateurs.

Si vous intégrez le contrôle du navigateur dans une application de bureau/mobile, vous pouvez demander des données binaires à l'aide des API OS/Framework et les transmettre à PDF.js en tant que Uint8Array.

Merci @yurydelendik pour vos liens. Je sais que PDF.js ne gère pas CORS. J'ai essayé les solutions envoyées par @timvandermeij et d'autres mais elles ont échoué. Je recherche les bonnes solutions d'implémentation/modifications une fois le repo pdf.js téléchargé. Merci

@yurydelendik J'ai également le problème de charger un fichier PDF à distance. Mais cette erreur ne se produit que dans Chrome.
PDF.js v1.0.1040 (version : 997096f)
Message : Réponse inattendue du serveur (0) lors de la récupération du PDF " http://bhpr.hrsa.gov/healthworkforce/rnsurveys/rnsurveyfinal.pdf ".

Vous pouvez voir que le PDF que j'essaie de charger se trouve sur un autre serveur sur lequel je n'ai aucun contrôle. Mais je souhaite quand même afficher ce PDF sur mon viewer.js

Je n'ai pas beaucoup d'expérience avec CORS mais j'ai créé un fichier crossdomain.xml de sécurité minimum sur mon serveur mais même alors cela ne fonctionne pas.

@hashbyte Vous aurez besoin d'un proxy pour le serveur. Un proxy très simple (développé par moi) est CORS Anywhere. Ajoutez simplement l'URL du proxy avant l'URL du fichier PDF, par exemple

"https://cors-anywhere.herokuapp.com/" + 
"http://bhpr.hrsa.gov/healthworkforce/rnsurveys/rnsurveyfinal.pdf" =
"https://cors-anywhere.herokuapp.com/http://bhpr.hrsa.gov/healthworkforce/rnsurveys/rnsurveyfinal.pdf"

Ensuite, encodez cette URL et mettez-la dans le paramètre file , et vous obtiendrez un lien qui peut ouvrir n'importe quelle page : https://mozilla.github.io/pdf.js/web/viewer.html ?file=https%3A%2F%2Fcors-anywhere.herokuapp.com%2Fhttp%3A%2F%2Fbhpr.hrsa.gov%2Fhealthworkforce%2Frnsurveys%2Frnsurveyfinal.pdf

Remarque : Si l'URL du PDF ne contient aucun signe de pourcentage ni aucun caractère & , un moyen plus simple d'obtenir rapidement un lien consiste simplement à ajouter l'URL de la visionneuse avant le lien (donc, sans encoder d'abord l'URL ). Ne faites cela que si vous saisissez manuellement l'URL (par exemple lors d'un test rapide) :
https://mozilla.github.io/pdf.js/web/viewer.html?file=https://cors-anywhere.herokuapp.com/ http://bhpr.hrsa.gov/healthworkforce/rnsurveys/rnsurveyfinal. pdf

Remarque : la démo CORS Anywhere n'est fournie que pour démontrer la fonctionnalité. Si vous envisagez d'utiliser cette fonctionnalité sur un site avec de nombreux visiteurs, veuillez héberger vous-même l'instance CORS Anywhere, pour éviter de mettre une charge injuste sur le serveur de démonstration public. Si je remarque que les performances de CORS Anywhere rampent en raison d'abus, votre origine sera mise sur liste noire. Lorsque vous hébergez CORS Anywhere vous-même, vous pouvez restreindre l'accès à votre site uniquement via le paramètre de configuration originWhitelist pour éviter ce genre d'abus.

Bonjour,
J'ai cette erreur lorsque je veux charger un pdf à partir d'une URL étrangère

Erreur : l'origine du fichier ne correspond pas à celle de l'utilisateur
jeter une nouvelle erreur ('l'origine du fichier ne correspond pas à celle du spectateur');

aidez-moi s'il vous plait !

J'ai cette erreur lorsque je veux charger un pdf à partir d'une URL étrangère

@gildassamuel voir #6916 pour plus de détails.

@jonasyuandotcom Dans le cas où le fichier est géré vous-même, vous pouvez mettre le fichier et les pdfjs sur un même serveur de fichiers.

Hé, j'ai suivi les instructions pour définir un "Access-Control-Allow-Origin" sur le serveur de fichiers mais je continue à obtenir cette erreur :

Les en-têtes http sont les suivants :

Tous les pointeurs seraient appréciés, même si vous n'êtes pas sûr de pouvoir fournir une cause possible au problème. Merci beaucoup!

@yjguoo Le message d'erreur et les en-têtes ne s'additionnent pas.

Je pense que la cible de redirection n'a pas les en-têtes attendus.

Visitez chrome://net-internals/#events et répétez les étapes pour voir les en-têtes réels de la redirection bloquée dans le journal.

Salut Rob merci pour la réponse rapide,

Je remarque que lorsque je saisis manuellement l'URL demandée "https://files.dev52.slack.com/files-pri/T076SHX5W-F07CGBKK2/git-for-beginners-handout.pdf", j'obtiens un en-tête de réponse différent du serveur de fichiers :

Notez que j'ai été acheminé vers un emplacement différent dans l'en-tête de réponse. Et à ce nouvel emplacement, j'obtiens un statut 200 ok.

Mes premières questions : y a-t-il une différence entre saisir manuellement l'URL dans le navigateur et via XmlHttpRequest ?
BTW j'utilise la visionneuse pdf.js par défaut (html css js) toutes les fonctionnalités fonctionnent sauf la demande d'un pdf d'origine différente (ei problème de demande croisée)
Deuxième question : pensez-vous que c'est un problème de mon côté ou la façon dont le viewer.js/pdf.js par défaut fait le XmlHttpRequest

Merci :)

Mes premières questions : y a-t-il une différence entre saisir manuellement l'URL dans le navigateur et via XmlHttpRequest ?

Oui, en particulier avec les demandes d'origine croisée. Lorsque vous effectuez une demande d'origine croisée, la demande n'est acceptée que si la demande est autorisée par CORS. Le navigateur émettra une requête avec l'en-tête Origin , le serveur peut l'utiliser pour décider d'approuver ou non la requête (en incluant l'origine demandée dans l'en-tête de réponse Access-Control-Allow-Origin ).

De plus, par défaut, les informations d'identification ne sont pas incluses dans les demandes d'origine croisée. Pour inclure les cookies, le serveur doit répondre avec Access-Control-Allow-Credentials: true et la requête XHR doit avoir l'attribut withCredentials défini sur true .

Deuxième question : pensez-vous que c'est un problème de mon côté ou la façon dont le viewer.js/pdf.js par défaut fait le XmlHttpRequest

Je pense que votre serveur doit être configuré différemment.

Voir la documentation sur MDN pour plus d'informations : https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
Ou lire la spécification de CORS : https://www.w3.org/TR/2014/REC-cors-2040116/

Salut Rob,

Je pense avoir résolu le problème en définissant également Access-Control-Allow-Credentials: true . Merci beaucoup pour l'aide <3. Cependant, je reçois un autre problème concernant une redirection et je ne sais pas si vous pouvez me donner des conseils. je fais du XHR
demande en utilisant l'URL#1 (le problème que vous m'aidez à résoudre). Ensuite, je reçois une redirection vers l'URL n°2 (statut 302). Mais URL#1 et URL#2 pointent vers le même serveur. Provoquant l'erreur suivante :

J'ai essayé de définir les mêmes en-têtes de réponse que pour l'URL n ° 1, mais je me rends compte qu'ils sont tous les deux sur le même serveur et que Origin est nul.

Je pense que c'est parce que les deux URL pointent vers le même serveur, donc l'origine de la redirection est NULL mais je ne suis pas trop sûr ? Maintenant, comment pourrais-je ajouter des en-têtes traitant de deux origines différentes, mais les deux URL pointent vers le même serveur de fichiers. J'ai essayé d'utiliser regex comme * mais apparemment ce n'est pas autorisé :( Encore merci !

Après une redirection croisée, Chrome définit l'en-tête Origin sur la valeur "null" au lieu de l'URL réelle - https://crbug.com/154967

Vous pouvez renvoyer sous condition un Access-Control-Allow-Origin avec la valeur null , mais uniquement si vous voulez que tous les sites Web puissent lire cette ressource . Si ce n'est pas le cas (ce qui est le plus probable), alors vous devez éviter la redirection. Par exemple, en envoyant directement la demande à l'URL de destination (si vous ne connaissez pas l'URL à l'avance, ajoutez un nouveau point de terminaison d'API à votre serveur qui renvoie l'URL de destination).

Merci! je vais me renseigner :)

Hé Rob, pensez-vous qu'il existe un autre moyen d'initialiser la visionneuse pdf ou pdf.js avec le src déjà défini et d'éviter les requêtes XHR tous ensemble ?

@yjguoo Vous pouvez encoder en base64 les données PDF et utiliser une URL de données. Pour les fichiers PDF volumineux, cela se traduit par une moins bonne expérience utilisateur (=page vierge sans barre de progression) car l'encodage des données en base64 augmente la taille du fichier de 33%. Je recommande de continuer à utiliser XHR pour cette raison.

Salut, je viens de tester et cela fonctionne si CORS est activé, mais ce que je vois, c'est que le fichier n'obtient pas le fichier en morceaux/plage si le fichier est très volumineux.

Résolu en ajoutant ceci dans .htaccess :
Ensemble d'en-têtes Accept-Ranges octets
Ensemble d'en-têtes Access-Control-Allow-Origin "*"
Ensemble d'en-têtes Access-Control-Allow-Methods "GET"
Ensemble d'en-têtes Access-Control-Allow-Headers "Content-Type, Range"
Ensemble d'en-têtes Access-Control-Expose-Headers "Accept-Ranges, Content-Encoding, Content-Length, Content-Range"

Merci!!!

@Rob--W C'était très utile. Il y a-t-il une possibilité de travailler depuis l'intérieur du projet (comme changer les en-têtes XHR) ? (à l'intérieur de worker.js)

Salut, pour ceux qui ont encore des problèmes avec cela, je l'ai résolu avec:

https://drive.google.com/viewerng/viewer?embedded=true&url=http://www.africau.edu/images/default/sample.pdf