Project Settings
Last updated
Last updated
The Settings section of your project allows you to configure Integrations, Authentication, Stages and Deployments, and also general settings within your project and stage. The following sections can be configured by clicking the Settings button found at the bottom of the left-hand navigation bar. Once the Settings tab is open, users can navigate between different tabs to modify and configure different Project and Stage settings. Aside from the global Project settings, all Stage settings will be applied specifically to the Stage currently selected within the Project.
The project settings carry special "property" that can ONLY be viewed and updated by either the Project owner, a User with Administrative permissions, or someone on a Team who has Project Admin access. This property is separated from other user roles since it can contain sensitive information. Project settings are also stored as an encrypted value to offer further security protection around this information.
Configurations to modify the Title, API Path, and other settings for the selected Stage and global Project.
The first group of configurations is general settings for the selected Stage within the project.
Stage Title: The title of the Stage which will appear in the project.
Stage Framework: Change the Framework type for the selected Stage. The framework does not inherently change anything about your stage other than the documentation for embedding your Forms and Resources based on the selected Framework.
Stage Path: The live endpoint for the selected Stage.
Use caution when modifying the Stage Path, any static references to this endpoint inside your app can break the application's connection to the Stage.
Protected Mode: Checking this setting will prevent project users from modifying Forms, Resources, Roles, and Project Access. In addition, the Project definition can only be deployed by a tag number. The Stage will display a shield icon next to its name when Protected Mode is active.
It's recommended to always enable Protected Mode for any stage connected to your Live application.
Default Stage: Select the stage that will be active upon opening the Project. The live stage will be selected by default. Users must ensure they are in the Live stage context when choosing a Default stage. To restore the Live stage as the default, remove the chosen stage by clicking the "x" button within the option value, then save the settings.
General settings for the Global project.
Project Title: The name of the project that will be used to identify the Project within the Portal
Project Description: The description is simply used to provide a brief summary of the Project which will display below the Project Title when viewing the Portal page.
Form Revisions: When active, enable Revisions for any Form or Resources created after the setting has been activated. Revisions will need to be manually activated for any Form or Resource that was created prior to enabling Global Form Revisions.
Click Here for more information on the different Revision options
Delete Project: Soft deletion of the Project which will be removed from the platform's UI.
Configure default settings that will automatically be set when a new Form or Resource is created. Settings will not retroactively affect Forms currently existing in the project. The following default settings can be applied to your forms:
Global Form Settings are the default form settings that can be defined on a global level and are used at runtime of the form when embedded into an application. Global Form Settings do not override any specific settings defined on a per-form basis. These settings are added at runtime using the Form Embedding System, but are not saved as part of the Form JSON.
Apply global templates to the Header and Footer of PDF forms.
Header & Footer Template
Inject HTML as a header/footer for every page of the generated PDF using the Header or Footer Template. The template must be valid HTML.
The following classes may be used to inject printing values into the header or footer:
date - The formatted print date, when the PDF was generated.
pageNumber - Current page number in the PDF.
totalPages - Total number of pages in the PDF.
title - The document title.
url - The document location.
The classes available in the header/footer are limited to these fields as supported in Puppeteer, the JavaScript library used to support PDF generation. To incorporate form data into a generated PDF, use the Form.io PDF Template Designer.
Use {{ formatDate( dateFormat, timezone ) }} with the moment-supported date format and timezone to customize the date displaying. Use Base64 for images.
Form.io uses DOMPurify to sanitize HTML. Sanitizing HTML and stripping any malicious HTML acts as a safegaurd to prevent XSS and other attacks. Form.io applies the default DOMPurify configuration that allows all safe HTML elements and attributes but does not allow SVG or MathML. Here the sanitize configuration can be modified to meet specific requirements. For more information, please refer to the DOMPurify documentation on Github.
The following attributes and properties can be added or allowed:
Tags
Attributes
URIs
The API Settings is where you can configure the API behavior of your Project. This includes configurations like setting up your CORS domains, creating Content Policies, generating API keys for project permissions, and more.
API Keys are designed for server-to-server communication to allow a backend server to talk directly to Form.io and have full access to all of the data, forms, resources, and other settings in a project. They provide full Ownership access, so use caution when generating API keys.
API Keys should never be used in a browser.
To use an API Key provide the key within the x-token header of a request.
x-token
23234lkj234lklkj234lkj2lkj34
Cross-origin resource sharing occurs whenever a browser detects a data request being made to a domain other than the one loading the page. The pre-flight request sometimes called an OPTIONS request, will ask the server if the domain has permission to perform the requested operation. By setting CORS domains you can limit which domains can access form definitions and form submissions.
CORS is enforced in the browser so API requests will still function as normal.
List all domains that will embed your forms separated by a space or a comma. For example:
For more information on how CORS works, we recommend reading the following article
Use * for all domains. The CORS setting defaults to this when creating a new project,
A policy is described using a series of policy directives, each of which describes the policy for a certain resource type or policy area. Your policy should include a default-src policy directive, which is a fallback for other resource types when they don't have policies of their own. There are specific directives for a wide variety of types of items so that each type can have its own policy, including
connect-src - for data loaded by URL
style-src - for style
font-src - for fonts
img-src - for images
media-src - for audio and video
script-src - for scripts
frame-src - for frames
worker-src - for workers
The policy is a string containing the policy directives describing your Content Security Policy. For example:
Secret used to encrypt data for fields with the Encrypted setting enabled.
Changing the key can cause the impossibility of decryption of stored data.
Settings here provide a way to create public configurations for a connected application you are developing. These configurations are then represented under the following API endpoint.
This can be used by your application to provide stage-specific configs that can be used for any purpose. In order to use these configurations, they must first be enabled by ticking the Enable Public Configurations checkbox.
Next, you can provide some key-value pairs of configuration names and the values of those configurations.
For example, the above configuration will be represented by the following JSON at the /config.json endpoint.
There are many times where you would like to have "global" values that can be represented on a per-stage basis within your forms. A good example of this is when you need to provide different URLs to your forms based on the stage in which the forms reside. In this situation, you can use the "Add Public Configuration to Form Schema" setting to enable the ability to expose these configurations to the evaluation contexts of your forms.
Once this is checked, all of these configuration variables will be added to each Form JSON schema under the "config" property of that form. To do this, you simply refer to this configuration using the following.
This can be used as follows within any component.
These configurations can also be used to configure the parameters for the Form Manager and FormView Pro
These settings enable you to add your own custom CSS and Javascript that will be used within the Form.io Project. You must also include the CSS or Javascript within your app to see the same functionality. Some common use cases for these settings are enabling the form preview to have the same styling as your application or to include custom components into the form builder.
A form module is a way to extend the basic functionality of the Form.io Renderer by allowing custom logic to be introduced into the runtime evaluation of a rendered form.
Click Here for documentation and examples.
Multiple third-party services can be integrated with Form.io. These integrations cover everything from Form Actions to Data Storage options to Email Transports. Please see below further Integration Options:
Email IntegrationsFile StorageGoogle Developer ConsoleSQL ConnectorForm.io provides multiple ways and 3rd party providers to Authenticate into the Form.io Developer Portal and your applications.
SAMLOAuthLDAP
