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

imported>Jason.nicholls
imported>Jason.nicholls
 
(32 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{DISPLAYTITLE:Session Variables}}
{{DISPLAYTITLE:Session Variables}}
[[Category:AppBoard 2.4]]
The Session Variable administration page allows the definition and default configuration for session variables within the AppBoard system.


The Session Variable administration page allows the definition and default configuration for session variables within the AppBoard system.
[[File:appboard-2.4-session-variables.png|frame|center|link=|Session Variables administration page]]




Line 8: Line 10:
Typical uses for session variables:
Typical uses for session variables:


* storing environmental information that is subject to change such as database hostnames, usernames, passwords.
* 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.
* 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 18: Line 20:
* Session Variables administration page to define and set defaults
* Session Variables administration page to define and set defaults
* URL parameters to override session variables (only allowed if configured this way)
* URL parameters to override session variables (only allowed if configured this way)
* Explicitly set through the use of a SHIM expression <tt>session.var.set</tt>.
* Imported at runtime dynamically, for example by pulling in additional user attributes from LDAP and assigning them to session variables.
* Imported at runtime dynamically, for example by pulling in additional user attributes from LDAP and assigning them to session variables.


=== Variable Scoping ===
=== 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 example, in a case where all three levels are defined (Global, Domain, and User) then the most specific version is used, i.e. the User version.
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 ==
 
[[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.
 
This dialog can be used to:


* Add new variables
* Delete variables
* Configure existing variables


== Managing Session Variables ==
The following table provides a description of the configuration fields when defining variables:
 
{|class='wikitable'
!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 <tt>STRING</tt>, but other types include <tt>BOOLEAN, NUMBER, INT</tt>, and <tt>DATE</tt>
|-
|''Scope''
|Check the ''Domain'' and/or ''User'' boxes allow for domain and user scoping. See the [[#Variable Scoping|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 [[appboard/2.4/admin/accessing_appboard#Session Variables|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.
** 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).
* ''LDAP:'' this is hidden unless the ''User'' scope is checked. This setting is not currently supported or used. Instead, for information on context variables from LDAP refer to the [[enportal/5.4/admin/user_administration/enPortal_LDAP_configuration#User_Context_Variables_from_LDAP|LDAP Configuration]] documentation.
|-
|''Ordinal&nbsp;Position''
|Can be used to order the list of variables in this dialog.
|-
|''Default&nbsp;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:
 
# Bring up the ''Session Variables'' administration page
# Select the appropriate domain from the ''Domain'' drop-down selection.
# Either select the domain itself or a specific user in the ''Users'' list.
# At this point the ''Variables'' pane should show any variables that are scoped for the selection made (either domain or user or both).
# Type in an override value for desired variable.


[[File:appboard-2.4-session-variables.png|frame|center|link=|Session Variables administration page]]
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.

Latest revision as of 17:47, 4 August 2014

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.
  • 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 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.

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.
    • 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).
  • LDAP: this is hidden unless the User scope is checked. This setting is not currently supported or used. Instead, for information on context variables from LDAP refer to the LDAP Configuration documentation.
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.