Community › Forge › Assets list › Shared Configuration Manager
shared-configuration-manager
Reactive icon

Shared Configuration Manager

Stable version 1.0.1 (Compatible with OutSystems 11)
Uploaded
 on 26 Feb
 by 
0.0
 (0 ratings)
shared-configuration-manager

Shared Configuration Manager

Documentation
1.0.1

Roles

To access the application, users must be assigned one of the following role classes defined at the application level.

  1. Operations — Operations users have access to all day-to-day operational features, including shared configuration management, queues, and deployments.
  2. Admin — Administrators enjoy full access to the application, but are uniquely able to view the audit report and manage settings related to the Lifetime API.

Initial Setup & Settings

For successful configuration of the application and seamless utilization of features like remote deployment, it is crucial to follow the steps listed below.

Lifetime URL

The base url of your lifetime environment. This is used to query your environments as well as handle your deployments.

Lifetime API Service Key & Expiration Date

In your lifetime environment, create a new service account. The designated URL for this page is: /lifetime/ServiceAccounts_List.aspx.

Ensure that you keep the expiration date and service key for subsequent reference. The application settings will serve as a repository for this data.

Target Environment

You must specify the desired target environment. We strongly recommend restricting deployments to higher-level environments like Test, QA, and Production, even though deployment to the development environment is possible.

The refresh button can be used to update your environment list should your Lifetime Url or Key change.

Batch Size

Specify the batch size for processing applications in the queue. Remember that the longer the batch size, the longer the deployment plan will take to execute.


Application Functionality

The main functionality of the application comprises two actions: shared configuration management and application deployment. Now, let’s examine each action closely and see how we can use them.

Shared Configuration Management

Users can create, delete, and edit shared configurations, mirroring the functionality available in the Factory Configuration application. For users unfamiliar with shared configurations, it’s feasible to incorporate application customization during the build process.

To generate a Web.config file, we generally use XSLT which stands for Extensibile Stylesheet language. If you didn’t already guess it, it is based on XML and is used specially for transforming XML documents. For more information on it, i would suggest your visit the following knowledge base on MDN.

Below we can see some examples of header customizations.

-- Add X-Frame-Options
<add name="X-Frame-Options" value="SAMEORIGIN" />
-- Referrer Policy
<add name="Referrer-Policy" value="no-referrer" />
-- Cache Control
<add name="Cache-Control" value="no-cache" />
-- Enforce Same Origin on Frame
<add name="X-Frame-Options" value="SAMEORIGIN" />
<add name="X-XSS-Protection" value="1; mode=block" />
-- Enforce Geolocation Policy
<add name="Permissions-Policy" value="geolocation=(self)" />

The following example showcases a configuration that appends two custom headers to each page load request.

-- Add Custom headers
<add name="X-OS-Custom-Test" value="SharedConfigurationManger" />
<add name="X-OS-Custom-Test2" value="Hello" />

You then add them to a configuration like below:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:output method="xml" indent="yes" encoding="UTF-8"/> 
   
    <xsl:template match="@*|node()">
        <xsl:copy>
            <xsl:apply-templates select="@*|node()"/>
        </xsl:copy>
    </xsl:template>

    <xsl:template match="/configuration/system.webServer/httpProtocol/customHeaders">
        <xsl:copy>
            <xsl:apply-templates select="@*|node()"/>
            <add name="X-OS-Custom-Test" value="SharedConfigurationManger" />
           <add name="X-OS-Custom-Test2" value="Hello" />
        </xsl:copy>
    </xsl:template>

    -- Insert additional template matchs here ( see below ) --

</xsl:stylesheet>

In another example, we can modify our request filters to block all un-secure HTTP methods. To accomplish this, we can add an additional template match. Consider the following which allows only GET and POST actions.

<xsl:template match="/configuration/system.webServer/security/requestFiltering">
  <xsl:copy>
    <xsl:apply-templates select="@*|node()"/>
      <verbs allowUnlisted="false"> 
        <clear />
        <add verb="GET" allowed="true" />
        <add verb="POST" allowed="true" />
    </verbs>
  </xsl:copy>
</xsl:template>

After creating a shared configuration in the system, you can apply it to one espace or apply it to a list of espaces at once. The team redesigned this process from the ground up to enable more granular control of pagination and the addition of espace and configurations filters.

Additional documentation can be found at the follow link: https://medium.com/@jmarchalonis/shared-configuration-manager-abc68792b119


1.0.0

Roles

To access the application, users must be assigned one of the following role classes defined at the application level.

  1. Operations — Operations users have access to all day-to-day operational features, including shared configuration management, queues, and deployments.
  2. Admin — Administrators enjoy full access to the application, but are uniquely able to view the audit report and manage settings related to the Lifetime API.

Initial Setup & Settings

For successful configuration of the application and seamless utilization of features like remote deployment, it is crucial to follow the steps listed below.

Lifetime URL

The base url of your lifetime environment. This is used to query your environments as well as handle your deployments.

Lifetime API Service Key & Expiration Date

In your lifetime environment, create a new service account. The designated URL for this page is: /lifetime/ServiceAccounts_List.aspx.

Ensure that you keep the expiration date and service key for subsequent reference. The application settings will serve as a repository for this data.

Target Environment

You must specify the desired target environment. We strongly recommend restricting deployments to higher-level environments like Test, QA, and Production, even though deployment to the development environment is possible.

The refresh button can be used to update your environment list should your Lifetime Url or Key change.

Batch Size

Specify the batch size for processing applications in the queue. Remember that the longer the batch size, the longer the deployment plan will take to execute.


Application Functionality

The main functionality of the application comprises two actions: shared configuration management and application deployment. Now, let’s examine each action closely and see how we can use them.

Shared Configuration Management

Users can create, delete, and edit shared configurations, mirroring the functionality available in the Factory Configuration application. For users unfamiliar with shared configurations, it’s feasible to incorporate application customization during the build process.

To generate a Web.config file, we generally use XSLT which stands for Extensibile Stylesheet language. If you didn’t already guess it, it is based on XML and is used specially for transforming XML documents. For more information on it, i would suggest your visit the following knowledge base on MDN.

Below we can see some examples of header customizations.

-- Add X-Frame-Options
<add name="X-Frame-Options" value="SAMEORIGIN" />
-- Referrer Policy
<add name="Referrer-Policy" value="no-referrer" />
-- Cache Control
<add name="Cache-Control" value="no-cache" />
-- Enforce Same Origin on Frame
<add name="X-Frame-Options" value="SAMEORIGIN" />
<add name="X-XSS-Protection" value="1; mode=block" />
-- Enforce Geolocation Policy
<add name="Permissions-Policy" value="geolocation=(self)" />

The following example showcases a configuration that appends two custom headers to each page load request.

-- Add Custom headers
<add name="X-OS-Custom-Test" value="SharedConfigurationManger" />
<add name="X-OS-Custom-Test2" value="Hello" />

You then add them to a configuration like below:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:output method="xml" indent="yes" encoding="UTF-8"/> 
   
    <xsl:template match="@*|node()">
        <xsl:copy>
            <xsl:apply-templates select="@*|node()"/>
        </xsl:copy>
    </xsl:template>

    <xsl:template match="/configuration/system.webServer/httpProtocol/customHeaders">
        <xsl:copy>
            <xsl:apply-templates select="@*|node()"/>
            <add name="X-OS-Custom-Test" value="SharedConfigurationManger" />
           <add name="X-OS-Custom-Test2" value="Hello" />
        </xsl:copy>
    </xsl:template>

    -- Insert additional template matchs here ( see below ) --

</xsl:stylesheet>

In another example, we can modify our request filters to block all un-secure HTTP methods. To accomplish this, we can add an additional template match. Consider the following which allows only GET and POST actions.

<xsl:template match="/configuration/system.webServer/security/requestFiltering">
  <xsl:copy>
    <xsl:apply-templates select="@*|node()"/>
      <verbs allowUnlisted="false"> 
        <clear />
        <add verb="GET" allowed="true" />
        <add verb="POST" allowed="true" />
    </verbs>
  </xsl:copy>
</xsl:template>

After creating a shared configuration in the system, you can apply it to one espace or apply it to a list of espaces at once. The team redesigned this process from the ground up to enable more granular control of pagination and the addition of espace and configurations filters.

Additional documentation can be found at the follow link: https://medium.com/@jmarchalonis/shared-configuration-manager-abc68792b119