Please give a brief summary of your issue: Updating the Webviewer’s auth and/or intercepting load calls to handle token refresh
Please describe your issue and provide steps to reproduce it:
Our implementation ties the Webviewer to an existing web app/portal. We currently handle authorization with a jwt token. Our standard practice is to use a Request Interceptor Service to add this token and handle refreshing the token when it expires. This works with the Angular HttpClient and we can make that work for some Webviewer-specific requests (getting custom search results, for example).
However, we have no way (that we know of) to do anything similar regarding the Webviewer’s loading GET requests (initial load or streamed chunks). We don’t even know of a way to update this token after it’s been given to the instance.UI object via loadDocument. The only idea we have is totally reloading the component, but we’re trying to avoid that as our current setup makes that a bit cumbersome.
Is it possible to intercept these calls or otherwise update the headers/authorization the Webviewer instance uses?
Please provide a link to a minimal sample where the issue is reproducible:
TBD
Unfortunately I’ll need you to clarify your issue and project setup a bit more. So you’re running a custom web app/portal and the server attached to this handles the app authorization? I’m curious how you have it working for some WebViewer requests but not with initial load / streamed chunks.
Are you using a server to handle document viewing with WebViewer?
Can you expand a bit more on how the auth token is given to instance.UI.loadDocument? Is this with the customHeaders property?
If you could provide us more information and some sample code that would be greatly appreciated!
Thanks for the response and apologies for any confusion.
I’m curious how you have it working for some WebViewer requests but not with initial load / streamed chunks.
I was unclear. The scenario we’re running into is not with the initial load or even short term streaming. We’re running into problems later on when that token has expired but the user starts streaming additional content. The current workaround seems to be forcing users to close the tab and reopen from our portal app, or refresh the page with the webviewer (we open webviewer in a new tab). We’d like to avoid that and find a best practice for indicating to the WebViewer that a new token needs to be used in subsequent requests.
Note: Initially I was drawing attention to two variants of this scenario - opening a new document in a webviewer tab whose initial “load document” token has expired vs. streaming additional content in a webviewer tab whose initial “load document” token has expired. Let’s focus on the streaming scenario because I’m starting to have doubts about the other…
Are you using a server to handle document viewing with WebViewer?
We are using our own .NET backend (with the PDFTron SDK) to modify and serve PDF (or XOD) documents to the WebViewer, yes.
Can you expand a bit more on how the auth token is given to instance.UI.loadDocument? Is this with the customHeaders property?
Yes, that’s correct, for the loadDocument call we are making use of the customHeaders property to send our token. We also attach that token as a header on our custom search API calls in the typical Angular HttpClient fashion (and since we have full control over those calls, we’re able to keep the token updated just fine).
Unfortunately, we do not currently have a way to update the custom headers on the fly using our APIs right now. This is something that we could add in the future, please check the change-log section for any updates: Apryse Documentation | Documentation
Don’t know if you’ve solved this since then, but we’ve been playing around with intercepting and inspecting requests to our document backend using a ServiceWorker. A ServiceWorker would also let you modify requests, too. Might be an area to explore for you.