Appboard/2.5/builder/system administration/session variables: Difference between revisions

imported>Jason.nicholls
imported>Jason.nicholls
 
(5 intermediate revisions by 2 users not shown)
Line 11: Line 11:


* storing environmental information that is subject to change such as database hostnames, usernames, passwords - and used in Data Source configuration.
* storing environmental information that is subject to change such as database hostnames, usernames, passwords - and used in Data Source configuration.
* associating extra information for domains and users, which can then be used for a variety of purposes such as modifying queries etc... This may be helpful in multi-tenanted deployments.
* associating extra information for domains and users, which can then be used for a variety of purposes such as modifying queries etc... This may be helpful in multi-tenanted deployments. Refer to the [[appboard/2.5/builder/dynamic_queries|Dynamic Queries]] documentation for more details.
* a central place to store simple key information used in multiple places
* a central place to store simple key information used in multiple places


Line 29: Line 29:


[[File:appboard-2.4-session-variables-manage.png|thumb|300px|right|Manage Variables dialog]]
[[File:appboard-2.4-session-variables-manage.png|thumb|300px|right|Manage Variables dialog]]
The default screen when accessing the Sessions Variable administration page provides the mechanism to override Domain and User scoped variables. To actually define and edit default values click the ''Manage Variables'' button to bring up the ''Manage Variables'' dialog as shown to the right.
The default screen when accessing the Session Variables administration page provides the mechanism to override Domain and User scoped variables. To actually define and edit default values click the ''Manage Variables'' button to bring up the ''Manage Variables'' dialog as shown to the right.


This dialog can be used to:
This dialog can be used to:
Line 60: Line 60:
* ''Encrypted:'' This flag will ensure the variable value is not displayed to the user in any context (instead, it will be displayed as repeated asterisks). ''Please note that the following caveats should be considered regarding encrypted variables:''
* ''Encrypted:'' This flag will ensure the variable value is not displayed to the user in any context (instead, it will be displayed as repeated asterisks). ''Please note that the following caveats should be considered regarding encrypted variables:''
** Encrypting a variable is a one-way operation: changing a variable marked as encrypted to unencrypted is not supported. Although the variable will still be functional, the strings will appear as encrypted values. The suggested alternatives are to either either delete the variable and re-create it, or re-enter the value in place of the encrypted string.
** Encrypting a variable is a one-way operation: changing a variable marked as encrypted to unencrypted is not supported. Although the variable will still be functional, the strings will appear as encrypted values. The suggested alternatives are to either either delete the variable and re-create it, or re-enter the value in place of the encrypted string.
** Updating the encryption key with portal KeyCreate will require a full archive and restore to convert variable def default values and domain/user values. These are not updated on restart as for other parts of the system. The recommended approach is to do a KeyCreate before building up content (if needed).
** Passwords are stored encrypted, refer to the portal [[enportal/5.5/admin/system_administration/CLI_utilities|KeyCreate]] command to change the default encryption key.
|-
|-
|''Ordinal Position''
|''Ordinal Position''
Line 83: Line 83:


As shown in the example screenshot at the top of this page, the domain ''System'' is selected which is showing a variable <tt>Test</tt>. As the field is blank there is currently no override, but the administrator could specify one here.
As shown in the example screenshot at the top of this page, the domain ''System'' is selected which is showing a variable <tt>Test</tt>. As the field is blank there is currently no override, but the administrator could specify one here.
== Examples ==
=== Data Source Configuration ===
Using session variables to store data source configuration can be helpful if this information is used multiple times (multiple data source configurations) and also for workflow where a development environment may have one set of details, while production has another, and the Export/Import feature is used to migrate configuration excluding the session variables.
In this example four session variables have been created for the database host, name, username, and password as shown below:
[[File:appboard-2.5-manage-variables-example.png|frame|center|Example session variables.]]
With the variables created it is now possible to create or modify the data source to use these variables. The ''Insert Expression'' button is a convenient way to have the appropriate SHIM expression text inserted for you. The ''URL'' field has the value below which is not completely visible in the screenshot:
<tt>jdbc:mysql://${shim:session.var.get('mydb_host')}:3306/${shim:session.var.get('mydb_name')}</tt>
The ''Password'' field is also a SHIM expression except the value is masked with asterisks.
[[File:appboard-2.5-session-variables-db-config-example.png|frame|center|Data Source configuration with session variables.]]
=== In Queries ===
Refer to the [[appboard/2.5/builder/dynamic_queries|Dynamic Queries]] documentation for more details.

Latest revision as of 08:35, 19 March 2015

The Session Variable administration page allows the definition and default configuration for session variables within the AppBoard system.

Session Variables administration page


Overview

Typical uses for session variables:

  • storing environmental information that is subject to change such as database hostnames, usernames, passwords - and used in Data Source configuration.
  • associating extra information for domains and users, which can then be used for a variety of purposes such as modifying queries etc... This may be helpful in multi-tenanted deployments. Refer to the Dynamic Queries documentation for more details.
  • a central place to store simple key information used in multiple places

Session variables can be used anywhere SHIM expressions are permitted using session.var.get.

There are a number of ways to set session variables:

  • Session Variables administration page to define and set defaults
  • URL parameters to override session variables (only allowed if configured this way)
  • Imported at runtime dynamically, for example by pulling in additional user attributes from LDAP and assigning them to session variables.

Variable Scoping

An important concept is that session variables are globally available but can actually have different values depending on the session and whether the session variable has been defined to have Domain and/or User scope. For a given session the most specific version takes precedence: user, then domain, then the system default.

Managing Session Variables

Manage Variables dialog

The default screen when accessing the Session Variables administration page provides the mechanism to override Domain and User scoped variables. To actually define and edit default values click the Manage Variables button to bring up the Manage Variables dialog as shown to the right.

This dialog can be used to:

  • Add new variables
  • Delete variables
  • Configure existing variables

The following table provides a description of the configuration fields when defining variables:

Field Description
Name Shows the name of the currently selected variable. This is not editable, if a variable with an incorrect name is created then delete it and create another.
Description This description is purely for the AppBoard administrator. Best practices is to provide some information around why and what the variable is used for.
Type Drop-down selection of the data type of the variable. The default is STRING, but other types include BOOLEAN, NUMBER, INT, and DATE
Scope Check the Domain and/or User boxes allow for domain and user scoping. See the Variable Scoping section above for more information.
Options
  • Server Use Only: on by default and means the variable cannot be modified by the client, with the exception of the administrator via the Builder. Disabling this option means the client can override this variable via URL parameters - see the Accessing AppBoard page for more information.
  • Encrypted: This flag will ensure the variable value is not displayed to the user in any context (instead, it will be displayed as repeated asterisks). Please note that the following caveats should be considered regarding encrypted variables:
    • Encrypting a variable is a one-way operation: changing a variable marked as encrypted to unencrypted is not supported. Although the variable will still be functional, the strings will appear as encrypted values. The suggested alternatives are to either either delete the variable and re-create it, or re-enter the value in place of the encrypted string.
    • Passwords are stored encrypted, refer to the portal KeyCreate command to change the default encryption key.
Ordinal Position Can be used to order the list of variables in this dialog.
Default Value Define the default value of this variable here.


Setting Scoped Overrides

The Managed Variables dialog allows for variables to be configured along with their default values. If the Domain and/or User scopes have been checked then the main Session Variables administration page is used to specify the Domain and User specific overrides.

To set an override:

  1. Bring up the Session Variables administration page
  2. Select the appropriate domain from the Domain drop-down selection.
  3. Either select the domain itself or a specific user in the Users list.
  4. At this point the Variables pane should show any variables that are scoped for the selection made (either domain or user or both).
  5. Type in an override value for desired variable.

As shown in the example screenshot at the top of this page, the domain System is selected which is showing a variable Test. As the field is blank there is currently no override, but the administrator could specify one here.


Examples

Data Source Configuration

Using session variables to store data source configuration can be helpful if this information is used multiple times (multiple data source configurations) and also for workflow where a development environment may have one set of details, while production has another, and the Export/Import feature is used to migrate configuration excluding the session variables.

In this example four session variables have been created for the database host, name, username, and password as shown below:

Example session variables.

With the variables created it is now possible to create or modify the data source to use these variables. The Insert Expression button is a convenient way to have the appropriate SHIM expression text inserted for you. The URL field has the value below which is not completely visible in the screenshot:

jdbc:mysql://${shim:session.var.get('mydb_host')}:3306/${shim:session.var.get('mydb_name')}

The Password field is also a SHIM expression except the value is masked with asterisks.

Data Source configuration with session variables.

In Queries

Refer to the Dynamic Queries documentation for more details.