Module:Futurama Website/Futurama Web API
- not applicable
From Futurama 21.03+ it is possible to make Futurama CSP proof. Within this page the steps will be explained that you need to make in order to get your application CSP proof. This can be done for both Futurama website applications as Futurama Web API applications.
Configure CSP for your application
To make sure your application is CSP proof, a few steps have to be taken. These steps will be explained below.
Setting up the baseCSPHeader
The first step is to configure CSP for your application, this means adding the baseCSPHeader and configuring the handlers and modules needed (see the Configuration security page for the configuration of the baseCSPHeader).
Set the render file
To make Futurama CSP proof, we also made changes within the render file. If no render file is configured within your web.config, you don't have to make any changes. When you have defined a render file within your web.config, make sure the render file within the latest folder within the FuturamaModules folder is used. Within the page Configuration rendering you can see how to set up a render file.
If you have defined a different render file, make sure to import the latest render file from the FuturamaModules folder and copy the changes made there to your own render file (when you have overwritten this within your own render file). These are, for example, changes to use the latest jquery version.
The changes to the render file are applicable if you have a website application or a web API application that returns HTML. When you have a web API application that returns FICO, no render file is used. When transforming the FICO to HTML, make sure the HTML is CSP proof.
Dynamic files for web API
With the configuration above, Futurama will remove all the inline styles and inline scripts, before returning the page. The styles and scripts that are removed from the HTML, will be within dynamic WebResource.ashx files. When using CSP within a web API, these dynamic files will be send in the response. These dynamic files should be retrieved after each request. See the Web-API page for more information.
Test your CSP application
After setting up the configuration, the application can be tested in order to check if no CSP errors occur. This test can be executed with the reportOnlyCSPHeader setting (see Configuration security). With this setting, CSP errors will be reported within the console log of your browser but your application will still work correctly. By checking your browser console log (by pressing F12) and clicking through the application, you can find the parts of your application that are not CSP proof yet. This can result in URL's that you have to whitelist within the baseCSPHeader or inline styles or scripts that are not correct yet.
Tips and Tricks
Above the steps are explained to make your application CSP proof. Next to this there are also some points to consider within your CSP proof application. These points will be explained below with some recommendations.
Create js files
Toggle content using css classes instead of inline styling
Default button styling
Without CSP, the buttons that are used get default styling from the browser. When using CSP, the structure of the button is changed and because of this, it doesn't get the default styling from the browser anymore. To make sure the layout of the buttons stay the same, these styles should be added in the stylesheet of the application. To make sure the same styling is used, add the style below at the top of your stylesheet. This is the styling that is used in Chrome, Edge and Firefox (this may vary for other browsers).
If you have any questions about this subject or if you want to provide us feedback please send us an e-mail.