Hi Team,
We are giving the web-viewer folder library path for rendering the pdf. In local it is working. But in our server we are getting path issue. In our angular project we are using only main.js.
Do you have CDN url for the library so that we don’t want to store the lib folder in our project and our path issue will be solved.
Regards,
Yuva
Hello, I’m Ron, an automated tech support bot 
While you wait for one of our customer support representatives to get back to you, please check out some of these documentation pages:
Guides:APIs:Forums:Hi there,
PDF.js Express does not have a CDN unfortunately. The reason for this is because Express leverages iframes, and loading assets inside an iframe from a 3rd party URL causes issues due to browser restrictions. It is highly recommended to load your assets from the same domain as your application.
Let me know if there’s anything I can do to help you with your path issues.
Thanks!
Logan
Thanks Logan for your reply.
In Adobe Experience Manager portal we have to store the PDF JS plugins folder. But it is not allowing to upload the files with 2 dots in the file name. Is there any possible to rename the files
Ex: webviewer.min.js to webviewer_min.js
Can you please help on this issue.
Below is the error message when upload the file with 2 dots in the file name.
Hi there,
Unfortunately this is a change we cannot make as it would be a breaking change for every other user. We also have a lot of other files that have multiple periods in their name, so renaming just webviewer.min.js won’t resolve your issue.
Thanks,
Logan
Thanks Logan for your reply,
We have stored the plugin in different domain, when the pdf loading we are getting cross origin domain.
I think iframe is blocking the API call.
We had some information from the PDFTRon site for cross origin,
We added domain in configorigin.txt in lib/ui folder. Still see the cross origin domain issue.
Did we miss anything from our end ?
Can you please help us in cross origin domain issue.
Hi there,
When using this approach you must use a config file to execute Express APIs. You cannot use the instance returned from the constructor promise when loading assets cross origin.
I believe you still see that first error message even when using a config file, but you can safely ignore it. To hide the error, you can append a catch call like so:
Express(
{
path: "https://yourwebsite/static/lib",
config: '/static/config.js'
},
element
).catch(() => { })
Thanks,
Logan
Hi Logan,
As you suggested, we have created a config file to execute the view document API. (both application & plugin under cisco. com domain)
Our application : https://trustportal-nprd.cisco.com ( From this site on click of document, we are calling the pdfjs plugins)
We stored pdf js plugins : https://www-stage.cisco.com/web/fw/ctp/wv-resources/wv-resources/lib
under the lib folder we created config folder and mention file.js → this is the config file
From this config file we are calling the WebViewer, PDF document file to load.
But still we are getting CORS issue.
As we discussed in mail, please suggest do we are missing anything?
Do you have any working sample code it is good to validate from our end.
Please help us in this CORS issue. Thanks in advance.
Regards,
Yuva
Hi there,
Does your server www-stage-cisco have proper CORS headers set? Is trustportal-nprd allowed to make cross origin requests to it?
Can you send me a screenshot of the exact errors you are seeing?
Thanks,
Logan
Good day Logan,
Have you been able to solve this issue? I am facing a similar situation. My config file is located in an azure storage (xxx.blob.core.windows.net/public) and my application runs elsewhere. I have whitelisted the domain of my application in ui/configorigin.txt but I am still getting the cross domain error.
Kind regards,
Hey!
That warning is expected and should not impact what you are doing. All it is saying is that you will not be able to use the instance returned from the WebViewer function (which is why you need a config file).
You should be able to safely ignore that warning.
Logan
Hey Logan,
Thanks a lot from your response. I managed to replicate the issue locally by pointing to the resource on the other domain. The actual issue is the fact that from inside the iframe, I try to access a button on the page on my server.
let signButton = window.parent.document.getElementById("sign-now");
Uncaught DOMException: Blocked a frame with origin "https://xxx.blob.core.windows.net" from accessing a cross-origin frame.
at https://xxx.blob.core.windows.net/public/js/signature.js:16:32
Any ideas how to get around this issue?
Regards,
Hi there!
There is no way to work around this specific error unfortunately. This is a security restriction imposed by web browsers that disallows iframes on a different origin to access the contents of the main window. Without this restriction, malicious code could be loaded in an iframe which would then have access to the main window, which is a huge security risk.
What you can do however, is use the postmessage API to send messages between windows. The only drawback to this is that the data sent must be serializable, so you cannot pass DOM elements. You may need to rework your code a tiny bit to make this work, but it is an option.
You could do some kind of flow where when your #sign-now button is clicked, you can post an “onClick” message to the iframe window, and handle the event in there.
Hope this helps,
Logan
Thank you so much for the detailed explanation.
I am giving it a try. Just hoping that it is the last hurdle.
Do you perhaps have an example of set up for this implementation of the we viewer with the config file. Just to make sure all is in order.
I am getting this error now, all my files (/pdfjs-express/public, config.js) are located in the remote server:
Uncaught (in promise) DOMException: Permission denied to access property "WebViewer" on cross-origin object [PDFJSDocumentType.js:1967](http://178.128.171.157:5010/static/js/pdfjs-express/public/core/pdfjs/PDFJSDocumentType.js)