Secured Scripting

You can execute Optiva Scripting functions in a secured mode. This feature limits the amount of damage a malicious user could inflict should they gain access to your scripts. (This could happen if they run all scripting in a sandbox environment that has limited permissions.)

Customers who are concerned about security or who are exposing Optiva to the internet should consider running in this mode.

Consequently, these changes have been made to the product.

  • A parameter controls whether you run Scripting in a secured or unsecured environment.
    1. Open the Web.config file that is in the inetpub\wwwroot\FsSvcCore directory.
    2. Find the ScriptMode parameter in the <appSettings> section. For Cloud customers, the default value is secured. For On-Prem customers, the default value is shown here.
    • <add key="ScriptMode" value="unsecured" />
      • The value of secured runs it in a separate AppDomain with limited permissions.
      • The value of unsecured runs the script inside of Optiva with all of the same permissions. This behavior is the same as older Optiva releases.
  • In secured scripting mode, the ObjectDataSet command cannot work simultaneously with other Optiva scripting API’s. To work directly with the data set of an object, you must call the ObjectDataSet command. Then make changes to the DataSet object. You can call the other Optiva scripting API’s to change or view information that is stored in Optiva; the information in the DataSet object is flushed back to Optiva. The DataSet is destroyed. Any attempts to access this DataSet result in .Net exceptions being thrown. You can make a new call to ObjectDataSet to retrieve a new copy of the DataSet. Then, you can make additional changes using that technique.
  • DataRowCurrent and DataRowProposed are not available in the secured scripting environment. They have been replaced by GetCurrentRowValue, GetProposedRowValue, and SetProposedRowValue. The new script hooks allow access to a single value on the row, not the entire row.
  • In “secured” scripting mode, the workflow is not allowed to communicate directly with the Report Server. Instead, it must use several new API’s to complete these tasks:
    • Send .xml files to the Report Server.
    • Optionally, send .xsd files to the Report Server.
    • Retrieve any files (e.g., .xslt files) that are required by the workflow.