Webviewer server TRN_FORWARD_CLIENT_COOKIES option not clear at all + wrong documentation?

Technical Support WebViewer
, ,
1

WebViewer Version: 10.0.1

I am referring to the option TRN_FORWARD_CLIENT_COOKIES for the webviewer server mentioned in the documentation at: https://docs.apryse.com/documentation/web/guides/wv-server-config/#same-domain-cookie-forwarding

My understanding with his option enabled would be that the client where the webviewer instance is loaded would send it’s cookies along to the webviewer server. In our situation the webviewer is hosted on a domain like https://xxx.lvh.me and the webviewer server is running on https://webviewer.lvh.me. They are on the same domain but when we give a url to load (eg: https://xxx.lvh.me/download/xxx.pdf) those cookies are not passed along by the webviewer. We authenticate first to xxx.lvh.me and set a cookie, with this option we though it would send the cookie along to the webviewer server so when it makes the request to https://xxx.lvh.me/download/xxx.pdf it would also be authenticated, but that does not seem to be the case.

Is our expectation of this feature incorrect? I did find some older references online (https://stackoverflow.com/questions/61135765/cant-load-pdf-file-while-using-pdftron-webviewer-server-in-local) where they mention the option withCredentials: true on the documentViewer (see https://docs.apryse.com/api/web/UI.html#.loadDocumentOptions) but that did not change the situation either.

Another remark is about some explanation about the caching that confusing. see https://docs.apryse.com/documentation/web/guides/wv-server-hardware-and-network/#using-customheaders-when-caching It mentions that if you provide customHeaders that they would be append to the query string of the given url when the webviewer server would make the request. That is simply not happening, it just passes it as headers.

Kind regards

2

Hello @johan.buts,

Thank you for posting on our forum,

TRN_FORWARD_CLIENT_COOKIES: This feature works only if WebViewer and WebViewer server share the same domain (e.g., apryse.com/domain1 and apryse.com/domain2). It forwards the cookies for the domain to the other path.

TRN_FORCE_URL_RECHECK: The description matches its functionality: WVS performs a 200 HEAD check on the file. If the check fails, the document will not load.

Custom headers are unrelated to query parameters; they are a separate feature. As the documentation states, all fields added to custom headers will be appended to the link when fetching the document, meaning the server will append custom headers when fetching from a file server.

Custom query parameters, passed with every request from WebViewer, are explained here:

Let us know if you need further clarification!

Best Regards,
Jacob Romano Carlsen
Web Development Support Engineer
Apryse Software Inc.

3

If people ever end up here, this is how we made the .TRN_FORWARD_CLIENT_COOKIES working:
We where able to pass the cookies if we hosted the webviewer server on client1.ourdomain.com/webviewer-server. We had to modify some nginx configuration to get it work but it seems to be working fine. The url’s of the documents to download are also of the format: client1.ourdomain.com/download/UUID.

location ~ ^/webviewer-server/(.*)$ {
    set $webviewer_upstream webviewer-server:8090;
    set $trace_id $pid-$msec-$remote_addr-$request_length;

    proxy_pass                          http://$webviewer_upstream/$1;
    proxy_set_header  Host              $http_host;
    proxy_set_header  X-Real-IP         $remote_addr;
    proxy_set_header  X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header  X-Forwarded-Proto $scheme;
    proxy_set_header  X-Request-Id      $trace_id;
    proxy_read_timeout                  900;

    # below is needed for ws
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";


    error_page 502 @proxy-down;
  }
1 Like