Change in behavior for error handling of anonymous views and forms

  • 16 February 2021
  • 0 replies
  • 161 views

Badge +3
 

Change in behavior for error handling of anonymous views and forms

KB003697

PRODUCT
K2 Five 5.6
BASED ON
K2 Five 5.6

Introduction

For added security, a new feature is introduced with K2 Five 5.6 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

When an error occurs on an anonymous view or form in K2 Five 5.6, the error message now contains a generic message with a CorrelationID. In versions prior to K2 Five 5.6, 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.

22193i4418C6361B9CD5BE.png

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 a user (administrator) with server admin rights 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 your administrator.

  • 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 your administrator and provide the CorrelationID from the message.

 

How does this change affect existing anonymous views and forms?

New K2 Five 5.6 installations

The new feature is enabled on all new installations of K2 Five 5.6.

Upgrade to K2 Five 5.6

When you upgrade from a previous K2 Five version to K2 Five 5.6, the new feature is enabled except if anonymous views or forms exist in your environment that use Error context fields prior to upgrading to K2 Five 5.6. 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 manually 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 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 your administrator if you want to increase this limit.

 

How to manually enable or disable the feature

Enable

  1. In the HostServer.Feature table of your K2 database, update the IsActive column of the SmartForms.AnonymousErrorHandling feature to true (1).
  2. Perform an IISRESET.

Disable

  1. In the HostServer.Feature table of your K2 database, update the IsActive column of the SmartForms.AnonymousErrorHandling feature to false (0).
  2. Perform an IISRESET.

0 replies

Be the first to reply!

Reply