Security Best Practice

We recommend that you create a new Application Pool and Website for Digitise Forms in IIS. This segregates Digitise Forms from any other applications that may be using the IIS default Application Pool and Website. See Install Appendix A, Install Appendix B, and Install Appendix C for more information on setting up IIS for Digitise Forms.

 

In addition, we recommend that the Application Pool does not use the default Application Pool Identity. This is because certain aspects of Digitise Forms will require permissions that the default Application Pool Identity should not have access to, e.g., remote network shares for PDFs and permissions to NDL Connect.

 

Application Pool Timeouts

Because Digitise Forms runs under an Application Pool in IIS, you will need to consider (and possibly adjust) the IIS timeout settings. If the IIS Application Pool times out, then your eForm will no longer be able to send requests (downloads or updates/submissions). This won’t be immediately apparent to the user of the eForm, and they will only become aware of this when they attempt to submit their data.

 

Adjusting the IIS timeout period has certain security implications – especially if a higher timeout period is used – including Digitise Forms becoming exposed to possible DoS and other attacks. In addition, setting a larger timeout period could increase resource consumption (i.e., more CPU and memory usage) which might impact the performance of the eForm.

 

If you are running Digitise Forms 1.8 or higher, users should be able to recover and complete their eForms following a timeout without experiencing any data loss. See the Form Timeouts topic for more information.