OpenWGA 7.10 - OpenWGA Concepts and Features

Design and development » Design configuration » Tab "Design Configuration"

Section "Publishing"

This section controls the publishing behaviour of OpenWGA for applications with this design. They therefor complement or set defaults for the "Publishing settings" of an OpenWGA application. Most of them can be overriden in the publishing configuration of the individual application if neccessary.

This section is introduced with two settings for special pages for the application design. 

  • The Home Page is a setting which defines a page on the application that should be shown when the application is called without specifying a special resource. 
  • The Login Page is a setting specifying a special page for logging in users with it. It is used when the user calls a WebTML-generated Login-URL (type="login").  This will only work if your application is open to anonymous access since the login page must reside in the applications design itself when set here. There are other possibilities when the login page is set in administration.

    In both cases you should specifiy a partial URL that must not begin with a slash. It is used to extend the base URL to the application that uses the design. For example imagine a home page setting of:

    html/default/home

    If an application using the design is called via the following URL:

    http://www.openwga.com/main

    Then the setting will be interpreted as:

    http://www.openwga.com/main/html/default/home

    This effectively will call a document named "home" in the application. By adapting the partial URL to your needs you could also address an individual WebTML module.

    The setting Default WebTML Output Encoding sets a default WebTML encoder for all WebTML tags of this design that are vulnerable for security threats based on "Cross site scripting". It therefor offers the ability to automatically prevent these kind of attacks in most cases, for example by choosing encoder "html" which will not let these tags put out any functional HTML tag. The affected functionalities are:

    • Output of <tml:item>
    • Output of <tml:input> in mode "view"
    • Output of <tml:urlparam>
    • Parameters on WebTML labels

    Individual tags can however override this setting with an explicit attribute "encode". As the WebTML code of an application must be created with this setting in mind - since unwanted encoding may break functionalities - the default setting here is "none" which does no automatic encoding.

    The setting "Design encoding" declares the text encoding that is to be used by text-based files of the design directory. OpenWGA will read those files using this encoding. We recommend using "UTF-8" wherever possible. The link "Enforce design encoding" below it will parse all textual resources and mark all errors according to the currently chosen encoding.

    This section is followed by some flag checkboxes triggering special application behaviour:

    • The flag Multi Language Content controls if OpenWGA should treat contents in applications of this design as being "language dependent" and therefor try to serve only languages that the user accepts (regarding his browser configuration) . It is enabled by default. Disabling it will keep OpenWGA from interpreting the language of content documents in any way. This only makes sense if there only is one language in the applications database which then will always be served, no matter what language the user may accept. This is typical for data-driven applications where the data is not available in multiple languages.
    • The flag Uses HDB interface may be checked if the design uses the "Hierarchical Database API" internally. It is obsolete for applications that target OpenWGA 5.0 or higher since in these versions the HDB interface will automatically be initialized on its first usage.
    • The flag Only accessible with administrative login marks an application that should only be available to logged in OpenWGA administrators. OpenWGA will prevent any HTTP access to it when the user is not logged in as admin and redirect calls to the administrative login page. 

    At the end there is the setting browsing security. It controls the ways that browser users of the design are able to access individual content in your application. You should consider changing this setting from the default value "Normal access" to a more restrictive one if you cannot rely on the built-in OpenWGA features for content access alone.

    OpenWGA automatically ensures that users cannot perform operations or see data in a way that is not permitted by its built-in Authorisation features, which are ACL and document level authorisation fields. Your application design does not need to enforce anything that is guaranteed by these features, nor is any special browsing security setting neccessary to enforce this. However your design may choose to enforce additional security restrictions that further reduce the users access beyond what is allowed by built-in authorisation, for example make some documents invisible or reduce the ways that docs may be modified. In that case it may be neccessary to adapt browsing security so that other OpenWGA features do not act as security holes to your designs restrictions:

    • The setting "No authoring" will prevent applications that use your design from being opened in authoring applications like OpenWGA content manager. This will keep author/editor users from modifying the content documents there in ways that are not intended by your design. So the functionalities offered by your design remain the only ways of modifying content data.
    • The setting "No authoring and content addressing" builds upon the previous setting by also disabling the possibility to choose the content to display via URL. This will keep all users from seeing content documents that they technically are allowed to see but your design does not want to show them. Note however that this will completely disable the usage of all URLs pointing to content and the only way to access your application will be by addressing layouts directly, i.e. use "contextless" requests explicitly addressing WebTML modules.