Log in to start a topic

Print action not passing viewer reportService defined securityToken

Posted by: dave.willis on 12 August 2024, 5:03 am EST

  • dave.willis

    • Post Options:
    • Link
      Copy

    Posted 12 August 2024, 5:03 am EST - Updated 12 August 2024, 11:15 am EST

    Good morning,

    I am using your activereportsnet-viewer version 18.1.1 (see here: https://www.npmjs.com/package/@mescius/activereportsnet-viewer), and I am defining the JSViewer like so:

    _scope.viewer = GrapeCity.ActiveReports.JSViewer.create({
   element: '#viewerContainer',
   reportService: {
      url: `${_scope.reportAPIEndPoint}api/reporting`,
      securityToken: bearerToken
   },
   availableExports: ['Xml', 'Pdf'],
   displayMode: 'single'
});

    with a custom toolbar action to print defined like so:

    _scope.viewer.toolbar.desktop.addItem({
   key: '$print',
   iconCssClass: 'fas fa-print',
   enabled: true,
   action: function (item) {
      _scope.viewer.print();
   }
});

    When clicking the print button the securityToken defined in the viewer reportService is not passed to the /api/reporting/export/* endpoint (resulting in a 401 unauthorised), however if for example I call the export to PDF action (as below) it does pass the securityToken in the Authorization header of the HTTP call:

    _scope.viewer.toolbar.desktop.addItem({
   key: '$pdfExportButtonKey',
   iconCssClass: 'fas fa-file-pdf',
   enabled: true,
   action: function (item) {
      var exportConfig = {}; // Default settings
      _scope.viewer.export('Pdf', undefined, true, exportConfig);
   }
});

    From what I can tell this appears to be an obvious bug, which is affecting our production environment now that we have turned on authorisation for our reporting API. Can you please raise this issue with your development team and in the meantime provide a work-around for this issue? I would rather not disable the authentication layer as this appears to be the only issue affecting us regarding it.

  • katyayny.raghuvanshi

    Posted 12 August 2024, 11:54 pm EST

    Hi Dave,

    Please refer to the attached sample that we tested, and it is working fine at our end. The security token is being passed while exporting the report to PDF via a custom button as well. Please see the attached screenshots as well. If the issue persists, please share with us your stripped-down, runnable sample replicating the issue so that we can investigate further.

    SecurityToken_v18.zip

  • dave.willis

    Posted 13 August 2024, 3:24 am EST

    Good morning again,

    Thanks for your prompt reply, however even the example you provided has the bug present when printing the report. Yes the initial export request has the security token passed in the Authorization header: https://imgur.com/a/hJPFHQu which is also passed in the same manner on the subsequent progress checks, however the final GET request in the chain that retrieves the report being printed does NOT pass the Authorization header and therefore the print action fails: https://imgur.com/a/0QF3Kex

  • katyayny.raghuvanshi

    Posted 14 August 2024, 1:10 am EST

    Hi Dave,

    Please refer to the attached screenshare video where we can observe the security token being passed while until the final GET request in order to successfully complete the PDF export process. Let us know if we are missing anything here.

    SecurityToken.zip

  • dave.willis

    Posted 14 August 2024, 4:27 am EST - Updated 14 August 2024, 4:48 am EST

    Good morning,

    I watched your video, you are exporting the report to PDF, that works perfectly at my end to; however the issue isn’t with the export buttons, it’s with the print button. The print action does not pass the security token on the final GET request, I just triple checked it in your demo solution and I can confirm 100% that it only happens when printing.

    Please bear in mind that I am in the UK therefore there is a long delay between messages being sent/received, and this issue is currently affecting our customers so I need to find a solution ASAP. Can I ask that this issue is raised with your developers so that a fix can be prioritised as it is now two days since I posted my original issue, and no work on your end has taken place to fix this bug.

  • katyayny.raghuvanshi

    Posted 16 August 2024, 7:02 am EST

    Hi Dave,

    We apologize for the delay from our end. Actually, we had a public holiday on August 15th, due to which we could not get back to you. Also, we could replicate the issue while printing the report using viewer.Print(). We have escalated the same to our development team [Tracking ID: AR-33967] and will get back to you as soon as we receive any updates from their side.

    We understand your concern and urgency, and we appreciate your patience in the meantime.

    Best Regards,



    Katyayny

  • katyayny.raghuvanshi

    Posted 20 August 2024, 12:20 am EST

    Hi Dave,

    Thanks for your patience!

    We have received an update from our development team. As per them, all the requests to the server have token. The requests to the “internal” URI don’t have a token, but such requests don’t need a token as they access the URI created with https://developer.mozilla.org/ru/docs/Web/API/URL/createObjectURL_static. The workaround for the issue would be to fix the cross-origin request problems inside the viewer.

    If the issue persists, please try sharing with us a stripped-down, runnable application replicating the same so that we can look at it and investigate further.

    We hope this helps!

  • dave.willis

    Posted 20 August 2024, 3:26 am EST

    Good morning,

    The requests are only ‘internal’ if the reporting endpoints ‘live’ on the same site as the viewer, however in our scenario the reports are served by a micro-service so all the calls are treated as ‘external’. In order to navigate this problem in the past (with for example the ‘/view/’ endpoints) we have had to remove the token requirement from these URLs, but ideally I would rather not have to keep adding exclusions to something that should be completely secure.

    I would like the propose that this behaviour is changed to support your customers who wish to serve their reports from a completely seperate service, and rely on (JWT) tokens to provide an auth layer as we do. There are no downsides to passing the security token with all the calls made regardless of whether the devs consider them ‘internal’ or not as by not doing so you are either forcing your customers to use your reporting solution in a very specific way, OR to compromise security of their platform for an arbitrary reason.

  • katyayny.raghuvanshi

    Posted 21 August 2024, 1:02 am EST

    Hi Dave,

    We have escalated this to our development team for their insights on the same, and we will get back to you as soon as we get any updates from their side.

    Thanks for your cooperation and patience with the issue.

  • katyayny.raghuvanshi

    Posted 28 August 2024, 12:30 am EST

    Hi Dave,

    Apologies for the delay in getting back to you.

    This behavior has been recognized as a bug and will be fixed in v18.2 ( ETA: October-mid, 2024). We appreciate your patience in the meantime.

Need extra support?

Upgrade your support plan and get personal unlimited phone support with our customer engagement team

Learn More

Forum Channels

  • © 2023 MESCIUS inc. All Rights Reserved.  ·  1.800.858.2739

    All product and company names herein may be trademarks of their respective owners.