How to use WebComponent when served from a separate subdomain

Technical Support WebViewer
,
1

WebViewer Version?
10.4

Do you have an issue with a specific file(s)?
No

Can you reproduce using one of our samples or online demos?
Don’t know, haven’t been able to find a sample where the WebViewer lib files are served from a different domain than the main app.

Are you using the WebViewer server?
No

Does the issue only happen on certain browsers?
No

Is your issue related to a front-end framework?
No

Is your issue related to annotations?
No

Please give a brief summary of your issue:
The WebViewer lib files are served from a different subdomain than our app. We’re trying to instantiate WebViewer.WebComponent but getting the error message…

Access to fetch at ‘http://dev-cdn.aristotle.local:3000/cdn/1.15.9/webviewer/ui/index-wc.html’ from origin ‘http://dev-poa.aristotle.local:3000’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. If an opaque response serves your needs, set the request’s mode to ‘no-cors’ to fetch the resource with CORS disabled.

Please describe your issue and provide steps to reproduce it:
Currently, I’m just trying to imlement locally, thus the urls in the error message above containing aristotle.local.

Instantiation

const viewer = await WebViewer.WebComponent( 
  {
    config: Utils.requireFromCDN('webviewer/ui/config.js'),
    disabledElements: defaultDisabledElements.concat(disabledElements),
    licenseKey: 'license_key',
    isReadOnly: true,
    path: Utils.requireFromCDN('webviewer'),
    preloadWorker: 'pdf',
  },
    element
)

What’s the correct way to use the WebComponent when serving the WebViewer lib files from a separate subdomain?

1 Like
2

Hi there,

Thanks for reaching out,

From the error message, it looks like you are experiencing CORS issue, could you please try following our CORS guide and see if that resolves your issue?

Best regards,
Kevin Kim

1 Like
3

Hi Kevin,

Thanks for the response. The following was done locally. I’m getting a different exception now, but still not working. I should mention that instantiating the WebViewer the legacy way (iframe) works fine without needing to add CORS headers to the local server.

New Exception

Failed to construct ‘Worker’: Script at ‘http://cdn.aristotle.local:3000/cdn/1.15.9/webviewer/core/CORSWorker.js’ cannot be accessed from origin ‘http://poa.aristotle.local:3000’.

NodeJS express server

import cors from 'cors'

// Changed
app.use('/cdn', express.static('../../ui/cdn'))
// To
app.use('/cdn', cors(), express.static('../../ui/cdn'))

// This mimics are environments in AWS where are app loads from xxx.aristotle.ai and our assets (including webviewer) load from cdn.aristotle.ai

UI WebComponent instantiation

// Utils.requireFromCDN returns an absolute URL to the path/file given
// Locally, this produces http://cdn.aristotle.local:3000/cdn/1.15.9/{path}

const viewer = await WebViewer.WebComponent(
  {
    config: Utils.requireFromCDN('webviewer/ui/config.js'),
    licenseKey: 'xxx',
    isReadOnly: true,
    path: Utils.requireFromCDN('webviewer'),
    preloadWorker: 'pdf',
  },
  element
)
1 Like
4

Hi there,

Thank you for your response,

It looks like you are still experiencing some kind of CORS issue, could you please try following the express guide here: enable cross-origin resource sharing

Also, I see that you use the config option in your WV constructor. This method was to originally circumvent the iframe being on a different domain:

Is the config file required for your use-casee?

Best regards,
Kevin Kim

1 Like
5

Nope, made no difference. I’m not sure CORS matters here, as it’s the browser throwing an exception when webviewer-core.min.js tries to instantiate a new worker with the following url…

http://dev-cdn.aristotle.local:3000/cdn/1.15.9/webviewer/core/CORSWorker.js

Both webviewer-core.min.js and CORSWorker.js are from the same domain - dev-cdn.aristotle.local

Here’s a stackoverflow question that better explains the problem.

1 Like
6

Hi there,

Thank you for your response,

For now this looks to be a known issue and is in our backlog to investigate.
We will let you know when this has been completed and you can also watch out for our changelogs

Best regards,
Kevin Kim

1 Like