Environment Administration
Overview
Environment Administration is where you can customize environment-related settings. For example, you can set up performance tracking, customize the site name, or set password requirements. Environment Administration is where you'll make all changes and customizations to your environment.
Environment Levels in Unqork
Environment levels (or stages) in Unqork support each phase of building and rendering applications. As customer applications advance through development, they generally pass through the following levels:
Environment Level | Description | Codebase | |
---|---|---|---|
1 |
Staging |
Where Unqork Creators Also known as Unqork Users, or Designer Users; is anyone who is inside the Unqork platform. configure applications. This non-production environment level is meant for test data only. This level is where you create and update configurations before promoting to QA for testing. Staging is an internal environment level and part of Unqork's cloud infrastructure. Staging offers both a Designer and Express View interface. |
Staging |
2 |
Quality Assurance (QA) |
Where Unqork Creators test and verify processes, artifacts, and ensure applications are built using best practices. This non-production environment level hosts test data only. QA is an internal environment level and part of Unqork's cloud infrastructure. QA offers both a Designer and Express View interface. |
QA |
3 |
User Acceptance Testing (UAT) |
Where the Creators and end-users End-users, also known as Express Users, are the individuals accessing an application through Express View. In most cases, end-users are the customers using the product. can view the latest build. Use this environment level to test your application's end-user experience. This non-production environment hosts test data only. UAT is an internal environment level and part of Unqork's cloud infrastructure. UAT offers both a Designer and Express View interface. |
UAT |
4 |
Production |
This is the live application and the only environment level where end-users can access it. This level is also the only environment level to store live client data. Following SDLC best practices, development should never take place in Production. |
Production |
Additional environments can also include Pre-Production (Pre-Prod) environment levels. Pre-Prod environments use the Production codebase. The progression order is Staging, QA, UAT, Pre-prod, and Production. Client leads decide the number of environments to use when developing a customer application.
To learn more about environment stages, including the release process for platform updates, view our Software Development Life Cycle Processes article.
Accessing Environment Administration
To access the Environment Administration page:
1. | At the top right of the Unqork Designer Platform, click Settings ▾. |
2. | Click Administration. |
3. | Under Environment, select Environment Administration. |
After accessing the page, you'll see various settings and options you can use to customize your environment. The remainder of this article navigates you through these settings and how to use them.
General
This section focuses on the general settings you can use to customize your environment. These settings include creating a site name, enabling custom login and logout modules, and determining if you want to capture all request and response bodies.
Using the menu below, select a setting:
|
Google Tag Manager
Unqork supports integration with Google Tag Manager for Google Analytics tag configurations. You can use tags for several purposes, including:
-
Scroll tracking.
-
Monitoring module submissions.
-
Conducting surveys.
-
Generating heat maps.
-
Tracking how end-users End-users, also known as Express Users, are the individuals accessing an application through Express View. In most cases, end-users are the customers using the product. access your site.
You can also use Google Tag Manager to add custom scripts to your application. To learn more, view our Environment Administration: Adding Custom Script Using Google Tag Manager.
The Google Tag Manager section of the Environment Administration page includes three fields:
-
GTM Container ID
-
GTM Environment Authentication
-
GTM Environment Preview
Only use the GTM Environment Authentication and GTM Environment Preview settings if you have multiple environments set up in Google Tag Manager.
To learn more about environments in Google Tag Manager, see Google Tag Manager's Environments documentation: https://support.google.com/tagmanager/answer/6311518/environments?hl=en.
Another solution for running different tags in different Unqork environments is to create one Tag Container for each Unqork environment. Then, add the environment-specific Container ID to each environment's Environment Administration page.
To set up Google Tag Manager integration in Unqork:
1. | In the GTM Container ID field, enter your Container ID. |
When you create a new Tag Container, Google Tag Manager prompts you to copy and paste the Tag Manager Snippet Script to every page of your website. Unqork performs this step for you. You only need to add the Container ID to your environment once.
2. | At the bottom of the page, click Save Changes. |
Unqork API
This section explores the various settings associated with APIs in Environment Administration.
Unqork API
Unqork has its own API APIs (application programming interfaces) are a set of protocols and definitions developers use to build and integrate application software. APIs act as the connective tissue between products and services. that lets you request and send data between systems. To use it, you must authenticate using an access token.
By enabling OAuth2 Password Grant in Environment Administration, your Unqork users can obtain an access token using their login credentials to make API calls.
To enable OAuth2 Password Grant:
1. | Set Enable OAuth2 Password Grant to (checked). |
2. | At the bottom of the page, click Save Changes. |
For more tips on using the Enable OAuth2 Password Grant setting, view the Best Practices section of this article.
Execution Limit
An execution limit is the number of retries a component or Workflow node attempts in a server-side execution. This setting is a helpful defense mechanism built into each environment.
Server-side execution requests have a two-minute timeout. If the module being executed has a configuration containing a larger number of components or Workflow node executions, it might timeout if the execution limit is too high.
Execution limits (or looping limits) prevent infinite loops in the form of two looping limit settings:
-
Looping Limit for Component Execution: The looping limit specific to component executions. By default, this value is set to 100 retries.
-
Looping Limit for Workflow Node Execution: The looping limit specific to Workflow node executions. By default, this value is set to 100 retries.
To change the execution limit for your components or Workflow nodes:
1. | In the Looping Limit for Component Execution or Looping Limit for Workflow Node Execution fields, enter an integer. |
2. | At the bottom of the page, click Save Changes. |
Session Administration
This section lets you determine how to control sessions in Designer and Express. For example, when end-users End-users, also known as Express Users, are the individuals accessing an application through Express View. In most cases, end-users are the customers using the product. log into an environment, they obtain an access token. This token verifies they have permission to log into your environment. But, the token only remains active for a set amount of time. After that time, Unqork logs them out, and they must log in again.
If your end-user leaves their device unattended while remaining logged in, this setting prevents someone from obtaining your end-user's token and using it indefinitely.
To customize your environment's session requirements, use the following settings in this section. Then, save your changes.
Setting | Description |
---|---|
Expire User Sessions in Express |
This drop-down menu provides you with opinions exclusive to Express sessions:
|
Inactivity Timeout |
The amount of time an user can stay inactive in Designer and Express before their token expires. This value must be less than or equal to the Session Timeout. The minimum time value is 5 minutes and the maximum is 1440 minutes (24 hours). |
Session Timeout |
The amount of time an user can remain logged into Designer and Express (with or without activity) before their token expires, in minutes. |
For more tips on using the Session Administration settings, view the Best Practices section of this article.
CSP and CORS
This section explores the different settings associated with Express Content Security Protocol (CSP) and Cross-Origin Resource Sharing (CORS).
Express Content Security Protocol (CSP)
Content Security Policy (CSP) is a security standard that informs the browser to allow or block loading content for a given site. For example, let's say you set up an iframe in your Unqork application that displays content from another site. You can use CSP to inform the browser that it's safe to load content from that site in your Unqork application. By default, Unqork environments have strict CSP settings. These settings help protect against threats, like data injection attacks. Only hostnames added to your CSP settings can load content into or out of your Unqork application.
To learn more about each directive, view the Mozilla developer CSP documentation: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy.
You can set up the following CSP directives in Environment Administration:
Directive | Description |
---|---|
Frame Source List (frame-src) |
The frame-src directive lists the frames that can be embedded in Unqork, and identifies the sources that can load <frame> and <iframe> elements. |
Frame Ancestor List (frame-ancestors) |
The frame-ancestors directive lists the frames that can embed Unqork, and identifies the sources where <frame>, <iframe>, <object>, <embed>, and <applet> elements can load. For example, to set up an iframe in Unqork that displays content from another site, add the site's hostname (or domain name) to the Frame Ancestor list. Issues arise if a source has its own CSP directives or an X-Frame-Options header that conflicts with your CSP directives. For example, the site you try to load content from might block framing. Adding the site's hostname to your Frame Ancestor List does not override the source site's restrictions. If a frame does not work as expected, verify that the source's CSP and X-Frame-Options do not conflict with your directives. |
Object Source List (object-src) |
The object-src directive lists which sources can load <object>, <embed>, and <applet> elements. Mozilla recommends restricting the object-src directive. To learn more, view the Mozilla developer object-src documentation: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/object-src. |
To add Content Security Policy directives:
1. | In the Frame Source List field, enter allowed sources, if required. |
To allow multiple sources, use a comma-separated list.
2. | In the Frame Ancestor List field, enter allowed sources, if required. |
3. | In the Object Source List field, enter allowed sources, if required. |
4. | At the bottom of the page, click Save Changes. |
Offline Mode
The Enable Offline setting enables offline access at the environment level. Enabling this setting lets you access offline-mode tools and features to:
-
Automatically register a service worker. Setting up this service worker lets your offline-enabled modules connect to the IndexedDB API APIs (application programming interfaces) are a set of protocols and definitions developers use to build and integrate application software. APIs act as the connective tissue between products and services..
-
Enable the Module Builder's Cache this Module to Allow for Offline Access setting.
To learn more about offline mode, view our Introduction to Offline Mode article
To enable offline access at the environment level:
1. | Set Enable Offline to (checked). |
2. | At the bottom of the page, click Save Changes. |
User Accounts
This section explores the different settings associated with User Account Lockouts and Express User Account Passwords.
User Account Lockout
The User Account Lockout settings control how many login attempts Creators Also known as Unqork Users, or Designer Users; is anyone who is inside the Unqork platform. can make before they are locked out of the Unqork Designer Platform. Administrators can specify maximum attempts in a specific time frame, including the lockout duration after exceeding the maximum attempt. After a Creator's account is locked, they receive an email informing them of their account status.
Administrators can unlock user accounts earlier using the Creator (User) Administration page. To learn more about unlocking user accounts, visit our Creator (User) Administration article.
Setting | Description |
---|---|
Maximum Number of User Login Attempts |
The number of failed login attempts allowed before a user’s account is locked. You can enter a numerical value between 2 and 10. By default, the value is 5. |
User Account Lockout Duration |
The amount of time a user's account remains locked, in minutes. You can enter a numerical value between 5 and 120. By default, the value is 30. |
User Login Attempt Duration |
The total amount of time between failed login attempts before the user is locked out of their account, in minutes. For example, using all default settings, a user can attempt to log in 5 times over the course of 30 minutes. If a user attempts to log in a sixth time in those 30 minutes, they are locked out of their account. You can enter a numerical value between 5 and 120. By default, the value is 30. |
Component Security
The Disable Safe HTML Filters in Content Components setting prevents use of the safehtml AngularJS filter in Content components. When enabled, Content components bypass safehtml filters in Express View.
To enable bypassing safehtml filters for Content components:
1. | Set Disable Safe HTML Filters in Content Components to (checked). |
2. | At the bottom of the page, click Save Changes. |
Best Practices
Using the menu below, select a best practice to explore it:
|
Server-Side Execution Request/Response Body and Debug LogsThe Server Side Execution Request/Response Body Log enables the logging of request and response bodies for all server-side execution modules.
|