as many of you probably heard, the Spring framework has this critical security issue: CVE-2022-22965.
ReportServer is not affected by this as of ReportServer 3.1.1. All previous versions are affected and should be upgraded immediately. We recommend to upgrade to the current ReportServer version 4.1.0.
Your ReportServer Team
ReportServer 4.1.0 is now available for all users. It contains many new features, improvements and bug fixes. An overview of the most important are shown below.
The BIRT libraries were upgraded to the newest version 4.9.0. More information can be found here.
As of ReportServer 4.1.0, “Write” permissions are needed in able to edit, create or delete a report variant. Previously, only “Execute” permissions were needed.
Table datasinks allow you to send and/or schedule dynamic list reports into to a given table in any datasource supported by ReportServer. This allows you to easily transfer data from MySQL to Oracle, for example. The destination table must exist and must be compatible with the dynamic list, i.e. the fields must exist, have the same name, and have compatible data types.
As of ReportServer 4.1.0 you can check permissions via the new “haspermission” terminal command.
The command allows to check if a given user has a given permission on a given target. Returns “true” if the user has the permission, else “false”.
The -g flag allows to check generic permissions. Documentation of these including the exact target types you can enter can be found here.
For other objects, e.g. Users, Datasources, etc., you can check the entity types here.
The following example checks if the user with id “6” has “Execute” permission on the “AccessRsSecurityTarget” generic target, i.e. if the user is allowed to log in into ReportServer.
The following example checks if the user with id 115254 has “Read” permission on the datasource with id 144497.
The “tableExists” terminal command allows you to check the existence of the “T_AGG_CUSTOMER” table as shown in the following example.
The “columnsExist” terminal command allows you to check the existence of a column list (CUS_CITY, myColumn) in the “T_AGG_CUSTOMER” table as shown in the following example.
The “columnsMetadata” allows you to fetch column metadata of the “T_AGG_CUSTOMER” table as shown in the following example.
Metadata documentation of the fields above can be found here. The first 8 columns are displayed by default and CHAR_OCTET_LENGTH is an optional column in the example above. You can choose to append any number of the listed column-description columns by passing their name as an argument.
The “datasourceMetadata” command is a very powerful command that allows you to dynamically call any method of the DatabaseMetaData interface.
There are any number of applications for this. You will need to specify the datasource you want to access, the name of the method you want to execute and its parameters. The command will look up a method matching the name and argument count. If there is exactly one matching method it will be executed.
Arguments passed are converted into the expected parameter types as need. Supplying the String “null” will evaluate to null as an Object. Examples:
Lookup JDBC minor/major version and driver
Fetch column metadata similar to the columnsMetadata example
Now you will be able to display some selected meta-data about your datasource from within the terminal. It features 4 sections: general information, url information, functions section and supports section. If you require more information still, use the “datasourceMetadata” terminal command as mentioned here.
Note that this information is also available in the new datasource information window as shown in the following screenshots.
The “env” terminal command now includes information on your internal datasource. Note that this internal datasource has to be set in the /fileserver/etc/datasources/internaldb.cf configuration file.
All terminal command results can now be redirected either to a file in the internal ReportServer filesystem (> for new files and >> for appending results), or to an existing datasink (>>>). In such way, you can send long command results per email, OneDrive – SharePoint (O365), etc.
You can now test your LDAP configuration with the new “ldaptest” terminal command and its subcommands as shown in the examples below.
The following screenshot shows the corresponding “ldapimport” results:
The “onedrive” terminal command allows you to access some onedrive api functions from within ReportServer. As of now it has the following commands: onedrive group getmygroups & onedrive group getdrivesof.
The following example shows how to acquire a driveId of group you belong to in order to configure the baseroot of a onedrive datasink.
Use onedrive group getmygroups to see which groups you belong to
Use the groupId of the group to acquire its drives with onedrive group getdrives of
Use the driveId to configure the baseroot of the datasink as such /drives/your-driveid/root:
The “ssltest” command allows you to test your SSL configuration as shown in the screenshot below.
In case you installed a server’s certificate, for example for LDAPS or LDAP StartTLS, this command is useful for testing the installed certificate analogously to the following: “ssltest ipOrHostOfYourServer 10389”
You ReportServer Team