Change in behavior for error handling of anonymous views and forms

[#1]

Change in behavior for error handling of anonymous views and forms

KB003683

PRODUCT

K2 Cloud Update 17

BASED ON

K2 Cloud Update 17

Introduction

For added security, a new feature is introduced with K2 Cloud Update 17 to handle all errors for anonymous views and forms.

Often when an error occurs through a SmartForm, the error does not contain a generic message, instead the full error message is shown from the underlying coding frameworks. Although detailed errors are useful to solution designers, they pose a security risk as this information can be used by potential attackers to understand the underlying platform and find a potential vulnerability.

To reduce the risk of errors leaking information, the anonymous error handling feature returns a generic message containing a CorrelationID when the authentication context is anonymous. Full error messages are still shown to authenticated users for forms that require authentication. By only showing full error messages to authenticated users, the risk is reduced so that internet facing forms that do not require authentication prevents information disclosure.

Table of contents

• Changes to error handling
• How does this change affect existing anonymous views and forms?

Changes to error handling

When an error occurs on an anonymous view or form in K2 Cloud Update 17, the error message now contains a generic message with a CorrelationID. In versions prior to K2 Cloud Update 17, you could see the full error message and use these details from the Error context fields in rules. See How does this change affect existing anonymous views and forms and Considerations for more information about Error context fields.

Anonymous views and forms:

• Views and forms that have the Anonymous Access option selected in the view or form properties

The image below shows an example of an error containing a CorrelationID.

When such an error occurs, the full error details can be found in Windows Event Viewer>Applications and Services Logs>K2, and can be identified using the CorrelationID from the message.

Only Nintex Customer Central can access the full error details from the Windows Event Viewer. We recommend you follow the next steps to test and debug an error on an anonymous view or form before contacting Nintex Customer Central.

• Check out the view or form and then deselect the Anonymous Access option in the view or form properties.
• Run the view or form to reproduce the error and get the full error message.
• Once all errors have been investigated and fixed, enable the Anonymous Access option again and check in your view or form.

If you can’t resolve the issue following the above steps and you need more details about an error message, contact Nintex Customer Central and provide them with the CorrelationID from the message.

How does this change affect existing anonymous views and forms?

The new feature is enabled on all K2 Cloud Update 17 tenants except if anonymous views or forms exist on the tenant that use Error context fields prior to upgrading to K2 Cloud Update 17. This is to allow you to update your views and forms by removing the use of Error context fields. Once you are done, you can contact Nintex Customer Central to enable the feature.

If you are not concerned about this security risk and want to disable the feature because you need detailed errors or are using specific rules to handle the errors, you can contact Nintex Customer Central to disable the setting.

Considerations

• The generic error message with the CorrelationID is used in the Error context fields (Message, Type, and Detail) of the Context Browser. These fields do not contain the full error details, meaning anonymous views and forms can't check for specific errors to drive logic based on the error details. You can still create rules based on the “When an error has occurred” rule event, but you can’t get the full error details from the error context fields. It is best practice to design the solution to prevent errors, rather than drive application logic based on error message text. For example, if a form creates a new customer record and the customer’s name must be unique, add a rule to check if such a record already exists before creating the new record, instead of trying to create the record and checking if an error occurs.
• The Log Size of the K2 application event log in Windows Event Viewer has been increased to 100MB to cater for additional error details. If your environment encounters large numbers of errors, this limit may need to be increased to prevent CorrelationID logs from being lost by changing the Log Size property in Windows Event Viewer>Applications and Services Logs>K2. Contact Nintex Customer Central if you want to increase this limit.