Dotkernel API provides all necessary tools to implement safe applications, however you will need to manually make use of some of them. This section will go over the provided tools and any steps you need to follow in order to use them successfully, as well as a few general considerations.
In order to validate user input, Dotkernel API makes use of laminas/laminas-inputfilter. It is strongly recommended that custom functionality parsing user input also make use of input filters to validate the data.
Content negotiation in Dotkernel API is done by a middleware configured using the config/autoload/content-negotiation.global.php file.
Whenever an endpoint needs custom Accept and/or Content-Type, make sure that you set them in the above file.
Read more about content negotiation and the way it is implemented in Dotkernel API.
Dotkernel API uses mezzio/mezzio-cors to handle CORS details.
The default configuration, found in config/autoload/cors.local.php, makes the application accessible by any origin.
Make sure your application specifies only the required origins when in a production environment.
This step is described in the CORS tutorial.
This project makes use of mezzio/mezzio-authorization-rbac to handle access control.
The default use cases have already been configured, but any custom functionality will require additional configuration to make sure it is protected.
Update the configuration file of this package (config/autoload/authorization.global.php) whenever you add new routes or roles.
Dotkernel API ships with two demo accounts: an admin account (admin) and a user account (test@dotkernel.com),
with public identities and passwords as described in the token authentication tutorial.
Make sure to update or remove these demo accounts in your production environment.
The error reporting endpoint (/error-report) is intended to be used by third parties to report errors back to your application.
This endpoint requires its own token type, namely an ErrorReportingToken, that is to be added in the configuration file for every application sending reports.
Since these tokens do not have an expiration date, consider periodically refreshing them manually.
This feature is configured using the config/autoload/error-handling.global.php file, under the configured ErrorReportServiceInterface::class key.
This file is visible to your VCS by default, so take care not to overwrite tokens locally and commit them to your production environment.
Additionally, make sure the ip_whitelist or domain_whitelist keys are set to your desired values, especially when in a production environment.
Read more about the error reporting feature.
In order to provide an interactive documentation, Dotkernel API implemented zircote/swagger-php.
Make sure not to include sensitive data as examples for any of the documented endpoints. It is not recommended to enable the documentation in a production environment.
Read more about the OpenAPI documentation.
Dotkernel API uses composer to handle PHP dependencies.
In time, make sure to review any common vulnerabilities and exposures for your dependencies.
You may also keep an eye on the Dotkernel API changelog for any updates relevant to your project.
*.global.php and *.php.dist configuration files are visible to the VCS, make sure not to include sensitive data in commits.*.local.php configuration files are ignored by the VCS by default and are the recommended place for sensitive data such as API keys.development mode is correctly set - do not enable development mode in a production environment.composer development-statusRead more about using Laminas Continuous Integration.