Form Server-Side Processing

This topic explains server-side processing when users submit a form in Insites.

Prerequisites

Comprehending this subject requires a prior understanding of the following topics:

• Liquid Markup
• Form Configuration Options

1. CSRF Token validation

The first thing that occurs before every POST request is a CSRF token validation. The system does not proceed with the user's session if it is not provided.

2. Find the form based on the 'form_name' or 'form_id' parameter

The system then tries to identify the form used to process the user's request. To do so, the server checks for the  or parameter. This parameter is automatically added to the page when the form is rendered using the tag described in the Form Tag documentation. If the value is missing or invalid, a '404' error is rendered. Otherwise, you can move on.

3. Check permissions

The next step is authorisation using Permissions. These are processed in the order they were defined - from top to bottom. If the authorisation fails, the server stops processing the form and handles authorisation policy failure (usually via a redirect or rendering '403' error).

4. Resource Owner authorisation

Once all authorisation policies pass, the next item to be checked is an authorisation for the resource_owner property. It checks if the currently logged-in user can access the resource with the given . If it fails, the server returns a '404' error.

5. Modifying the user input using 'default_payload' JSON

The next step is to extend or overwrite the user's input with . This is where Liquid code is evaluated on the server side. If the evaluated Liquid code is not a valid JSON, the server raises a '500' error and automatically creates a relevant Log. The most useful variables used to build are and variables.

6. Validating the user input

The result of merging the user's input with is then run against validation rules defined for each field. If at least one validation fails, the server renders a response based on the format. For HTML, the errors are added to the variable inside the relevant field, and the server renders the Page based on the parameter passed to the server. Additionally, the is evaluated and set if provided in the configuration. It is then accessible using the variable. For JSON, a JSON object is returned with a populated key. The status code is '200' in both scenarios.

7. Calculating changes

If validation passes, the changeset between the existing state of the resource and user input is calculated and made accessible via the variable.

8. Persisting changes

The resource's new state persists in the database. In the case of the rare scenario of an internal server error, the changes are rolled back, and the server renders a '500' error.

9. Processing callbacks

The next step is to process the callback synchronously.

10. Schedule processing 'AsyncCallback' processes

The system then schedules asynchronous callback processes in the background.

11. Schedule sending notifications

The next step is to schedule all notifications (email, SMS, API calls) to be processed in the background.

12. Rendering a response

If the format is set to HTML, the property is evaluated and set, and then the property is evaluated to determine where the user should be redirected. The server renders a '200' status for a JSON request and serializes the form and a few basic properties (like ) to JSON.