JSReport, brief audit.
In order to verify if JSReport is suitable for our needs one thing we must check is the licensing because it uses a remote server.
jsreport can be run on our own servers.
We may be able to use a free license during development. If we grow beyond 5 report templates we will need to subscribe for a yearly enterprise license.
Licensing Purchase URL: https://jsreport.net/buy Note: The enterprise license is only for one instance of the jsreport, to run multiple we would need an enterprise scale license. That is kind of pricy for us, so lets aim for 5 reports or only 1 jsreport instance for now. I estimate whilst getting started, the number of reports we need and to generate are going to be within this tolerance.
Note: A recent post on the jsreport.net blog indicates the licensing has been simplified. The above may not hold 100% true. https://jsreport.net/blog/simplified-licensing
A license key is checked by a remote server, as such we must understand the behavior. We can't have the software leaking any private information from the report templates/data therein. The implementation does a post to an https URL.
License verification URL: https://jsreportonline.net/license-key File: node_modules\jsreport-licensing\lib\licenseing.jsreport
Note: This needs to be allowed through firewall in order to verify the license.
If you add more than 5 templates without a license, then the jsreport instance is put into a 1 month trial this should be suitable for developing a few reports and testing the viability of this reporting solution.
Another concern is, what if the remote URL cannot be accessed in a scenario such as:
- It goes down or returns error either temporarily or for good at some point in the future.
- The Internet connection stops working but we still want to use jsreport inside our network?
Thankfully in a show of good design/future proofing, the licensing code does appear to have a fall-back to an enterprise license if the verification server is unreachable or sends back a non 200 HTTP status code, this also kicks in after a timeout of 3 seconds, which I am assuming handles a case of slow connection/IO delay or if DNS is down/slow. This satisfies any concern about the reporting solution being unavailable during network or remote licensing service outage.
From reading the code what I can gather is a license response would look something like this.
HTTP Status 200 OK.
An invalid license. Causes jsreport instance to fail starting.
{
status: 1,
}A successful license validation. Type can be either: trial, free, subscription, enterprise
{
status: 2,
type: 'enterprise',
expiresOn: 'assuming date-time',
license: '???'
}A security hash is generated from the licensing info JSON and stored over-writing the license JSON file. This could pose a threat, if malicious code can be injected from the verification server, or by a server posing to be the verification server (MITM attack).
The license JSON file is read in and parsed with JSON.parse. So long as we can trust JSON.parse not to have an exploit / evaluate or buffer overflow etc, then we should be able to assume a minimal risk from the solution it's self. Although if report's somehow opened up a LFI, they could in potentially load up the JSON license file, although this is unknown.
I have my concern, but I will consider it a low risk.
JSON.stringify is used when calculating the hash. This assumes that JSON.stringify will always output keys in the same order. The docs state that for non-array properties, order is not guaranteed.
Properties of non-array objects are not guaranteed to be stringified in any particular order. Do not rely on ordering of properties within the same object within the stringification.
This could cause verification to fail however, in practice with named keys it appears the v8 engine implementation outputs the keys in canonical order.
It appears further configuraiton / extension is required to retain templates/reports.
We do use postgresql and could store the reports on that if we wanted. https://github.com/jsreport/jsreport-postgres-store
Or on the file system. https://github.com/jsreport/jsreport-fs-store https://github.com/jsreport/jsreport-fs-store-2
For ease of development, and using external tools that the developers are familar with, the file system is posisbly the better setup for development. But the database may be better for deployment over entire distributed network.
jsReport can generate a shareable link to a report. We need to check authorization to ensure only logged in users can view reports, and restrict visibility of data and reports.
https://jsreport.net/learn/authentication
Authentication does allow for configuring a remote token based authentication. We could link this in with our existing auth so that we have consistency for our sign-in and management of users in one spot. Nice!
A token based wrapper would have to be implemented, I think we were discussing using jwt anyway.
jsreport can generate PDF and Spreadsheets as well as interactive reports.
Actual report contents.
Q. Can we use custom modules, js code, d3.js, etc?
A. Yes it appears so, but they may need some additional configuration to allow it to be required into a report template.
Q. Can we use websocket with custom communication handling as a source of data?
A. This remains to be seen. I assume yes if we write our own extension, or implement on a per report basis.
Q. Can postgresql be used as a data source?
A. Yes.
Q. Can rabbitmq stats API be used as a data source?
A. Yes, but this will need to be implemented, a breif look at writing own extension appears like it is possible.
Q. Realtime datasource updates?
A. Yes.
Q. Dashboard functionality?
A. Yes.
Q. Scheduled reports?
A. Yes.
Q. Emailing reports from schedule?
A. Remains to be seen, assuming yes.
Q. Could the dashboard trigger events in remote services and gather results? Such as running tests and compiling results, asking for stats from server instances etc.
A. I think so with custom extensions.
Q. Can this intergrate with an existing express webserver?
A. Yes it appears so.