The main enhancement is the implementation of an alternative authentication mechanism through JWT, thought mainly for machine to machine scenarios, in which an external backend wants to execute reports as a server and not as user.
An independent security configuration file for the SWI has been implemented.
A new security provider has been implemented. This gives a new login method call that requires the token. Then the token is validated.
The rest of api method calls are exactly the same, as the token has to be inserted in the Authorization field of the http header.
The token must include the following field in the payload:
username: The username
securityGroup: The security group that the user will use.
culture: User culture
exp: Within the JWT standard, the token expiration time is specified.
Small modification has been done to improve the behaviour regarding the input restrictions sent in the executeReport and executeReportToResult methods. Before, only the input restrictions set in the method call were passed to the report, deleting the default values configurated in the report itself and then failing the execution. Now, the input restrictions set in the method call are set in the initialization of the report but keeping the value of the rest of the existing input restrictions. In this way, some input restrictions (prompted or not) can be set through the method call and others from the report (default values, those razored in the report execution init script, etc)
For example, generating the JWT token from PHP using the lcobucci/jwt library:
<?php
use Lcobucci\JWT\Builder;
use Lcobucci\JWT\Signer\Hmac\Sha256;
use Lcobucci\JWT\Signer\Key;
$time = time();
$token = (new Builder())
->issuedAt($time)
->expiresAt($time + 3600 )
->withClaim('culture','English')
->withClaim('securityGroup','Default Group')
->withClaim('username','test')
->getToken(new Sha256(),new Key('SecretKey'));
Then in the view, the token is added to the headers:
The main enhancement is the implementation of an alternative authentication mechanism through JWT, thought mainly for machine to machine scenarios, in which an external backend wants to execute reports as a server and not as user.
Small modification has been done to improve the behaviour regarding the input restrictions sent in the executeReport and executeReportToResult methods. Before, only the input restrictions set in the method call were passed to the report, deleting the default values configurated in the report itself and then failing the execution. Now, the input restrictions set in the method call are set in the initialization of the report but keeping the value of the rest of the existing input restrictions. In this way, some input restrictions (prompted or not) can be set through the method call and others from the report (default values, those razored in the report execution init script, etc)
For example, generating the JWT token from PHP using the lcobucci/jwt library:
Then in the view, the token is added to the headers: