OpenWGA 7.2 - OpenWGA Concepts and Features


Personalisation

Personalisation is a technology in Web Content Management which allows adapting the output of published data to the individual user.

The basis of this technology is the ability, to customize the session of the current user in a way that influences the output. So generally speaking every feature of WebTML that   stores data to the session - like WebTML session variables - may be called personalisation. However this data is transient and therefor not suitable for really adapting the browsing experience of a special user in a permanent way.

In OpenWGA the term "personalisation" therefor stands for storing data about a special user in a persistent way.

Basis of OpenWGA personalisation is the user profile. This is a special document available for (almost) every user which is able to store custom items, just like content documents do. However a single user profile document is only available to the associated user and therefor may be used to store data that is only to be used by him.

Also stored on the user profile are the users individual registration of WebTML portlets. who may be regarded a part of the OpenWGA personalisation feature.

User profile documents are normally stored inside the OpenWGA content store of the application itself. They may however also be stored in a separate OpenWGA content store only responsible for storing user profiles of a whole OpenWGA domain (see Domain wide profiles).

User profile documents do not need to be created manually. On the first access of a new user they are created automatically by OpenWGA.


Personalisation modes

The personalisation mode is an administrative configuration setting determined for each individual OpenWGA web application (on section "Publishing settings"). It chooses a technique how OpenWGA personalisation tries to recognize individual users across multiple browser sessions and then assigns them their personal user profile.

Mode "Session based (no persistence)"

This mode does not persist user profiles and portlet registrations. Instead a temporary profile is created for each user session which is discarded at the end of the session.

This is the default mode since OpenWGA 6, because it does not create any persisted data while still allowing every application to leverage personalisation features. It however is unable to store any data for a user that survives browser sessions.

Another concern with this mode regards cluster environments. The profile is attached to the server session as a "transient property", therefor it is not transported to other cluster nodes. If a user switches the node he loses his profile. You can prevent this by enabling additional (expert) option "Serializable user profile on session". This allows the cluster nodes to serialize the profile to other nodes. Be aware however that this may greatly increase the session synchronisation traffic in your cluster as the user profile may carry large data and is modified frequently.

Mode "Automatic / cookie based"

For applications in this mode a personalisation cookie is stored to the users' browser identifying the individual user via his automatically created "personalisation id". This cookie then can be recognized by OpenWGA on all further browser sessions and used to identify the user and assign him his user profile. The cookie is set with a maximum age of 1 year. It is again set to last a complete year at the beginning of every new browser session, so that the cookie does only expire automatically if the user has not accessed the site for one year.

This is the most robust persistent mode as every user at every time has access to a profile. It however has also it's drawbacks, described in the following sections, that you should be aware of.

Security concerns

One security concern is that the user profile is not really assigned to the user himself but actually to the browser that stores the cookie (or more precisely: The browser profile of the current OS user). Anyone using the browser of the given user (under his operating system account) will have access to the user profile. Protecting the user account from malicous access should prevent this security problem.

Another concern is about the Cookies themselves: They normally are transmitted in plaintext and may easily be sniffed. Additionally they are stored in the users file system in a normally unprotected way and may be fetched from there. That way someone else may gain access to the cookie content and use it to create a cookie with the same content for his own browser, therefor gaining access to the other users profile. So without any further adaptions user profiles in this mode should not store any confidential data.

You can improve the security of this mode by enabling the optional publishing setting Secure application mode for the application in OpenWGA admin client. This can be done if your OpenWGA server is also able to serve requests via an encrypted protocol (mostly HTTPS). Applications in secure application mode will only serve requests via secure protocols. If they are requested on an unsecure protocol they redirect the browser to a secure one. Additionally the personalisation cookie is then stored as "secure cookie", which will prevent the browser from sending it over unsecure protocols and may cause it to store it in an encrypted way.

Profile flooding because of bots

Another problem with the automatic mode may arise because of bots that access your site. These normally do not accept persistent cookies, so OpenWGA regards them new users each time they visit your site and creates an additional user profile  for them. While OpenWGA prevents this most of the time internally (the profile is only stored if the client accepts and stores the session cookie) some bots still manage to create user profiles. This leads to the creating of many unnecessary user profiles. There are two things you can do against this:

  • Prevent user profile creation for known bots: OpenWGA can prevent profile creation for bots who use an uniquely identifyable user agent. This is a unique string given by most internet clients as HTTP header to identify their type. Go into OpenWGA admin client, enable "Expert mode" by the checkbox to the top right and navigate in the menu to "Configuration" > "Advanced Configuration". There under tab "Bot Agents" you can tell OpenWGA about user agents known to be bots. Some should come preconfigured with OpenWGA but you can always add more. Bot agents are specified as regular expressions which are matched against the user agent of each request. If the user agent of any request matches a known bot agent OpenWGA will not create a persistent profile for that client but create a temporary one instead.
  • Regularely cleanup your personalisation databases: Experience shows that you cannot prevent all bots from creating user profiles. If they use regular browser user agents and are able to accept session cookies they are almost indistinguishable from normal clients, at least for automated processes. The only way to get rid of those is to cleanup user profiles that haven't been used for a time, assuming that they were either created by a bot or by a real user who will not mind if you clear his settings after a time that he has not accessed your site.

Mode "Login"

In login mode OpenWGA uses the login by which a browser user authenticates to the OpenWGA domain as identification. It is more secure than the "automatic" mode as it is bound to the OpenWGA authentication mechanism and the data neccessary to access the cookie - mostly a user/password combination - is not stored anywhere it can be stolen.

Its main drawback is the fact that anonymous users will have no user profile. The WebTML code of the application therefor will not be able to use personalisation features until the user logs in to OpenWGA.


Accessing the user profile

WebTML and TMLScript provide many ways to access the user profile in OpenWGA design.

One way to store data to the user profile is to use a WebTML form with attribute source set to "profile". The inputs defined inside the form will get stored as items to the profile when the default action $store is invoked on it.

<tml:form id="profiledata" source="profile">

  Your name: <tml:input name="name"/><br>

  Your date of birth: <tml:input name="birthdate" type="date"/><br>

  <tml:button clickaction="$save">Save</tml:button>

</tml:form>

Profile items can be retrieved using <tml:item type="profile"/>:

Welcome back, <tml:item name="name" type="profile"/> !

In TMLScript the object TMLUserProfile "this.profile" represents the profile of the current user and can be used to retrieve and store profile items:

profile.setItem("verified", true);


return profile.item("username");

Modifications done directly to the user profile in TMLScript are stored automatically at the end of the request.

Just like content documents a user profile also has metadata fields, offering some general data about it. See the Metadata of type="profile" for a reference of available fields. They can be retrieved using WebTML tag <tml:metadata type="profile"/> or TMLScript methods profile.meta() / profile.metaList().

Domain wide profiles

A special feature named "domain wide profiles" allows to share user profiles accross all web applications of an OpenWGA domain. That way all these applications have access to the same profile and their items. The user profiles for those applications are then no longer stored on their individual OpenWGA content stores but in one central OpenWGA content store.

This is to be enabled in OpenWGA admin client on the configuration of an OpenWGA domain. Editing the configuration you can enable the checkbox "Domain wide profiles":

screenshot_99(010).png

The settings that appear when selecting this checkbox closely resemble the "Content Store" part of web application configuration. You will be able to select an OpenWGA content store from your registered database servers, even to create one for the platforms where this is available. After choosing the content store you can save the configuration to enable domain wide profiles.

After enabling this the user profile of all applications in the configured domain will use the same user profiles.

Statistics

Every single user profile has metadata fields to store statistic information about the usage of the profile.

Which fields are actually used depends on the personalisation statistics mode which is chosen for the individual application.  The following three modes are available:

  • No statistics: Completely disables collecting of statistics.
  • Collect session statistics (default): Collects statistics at the beginning of every session to track the number of sessions and the date of the last session.
  • Collection session and single request statistics: Collections statistics on every request to track the number of requests per session.

Choosing a statistics mode is mostly dependent on what data you will actually use from the user profile, having in mind that more exhaustive statistics collecting may also degrade the application performance. Mode "Collect session statistics" is the default mode as it collects valuable data to do user profile maintenance but does only effect the first request of every session.

The statistics mode can be explictly set as additional publishing option in OpenWGA admin client:

  • Open the configuration of your application under menu "Web Applications" and click the "Edit" button
  • In section "Publishing settings" click "Show/Hide more options" and find option "Personalisation statistics". Choose it to add the option to the configuration
  • Choose the desired statistics mode and click "Save"

The statistics-related metadata fields can be retrieved from within WebTML requests as metadata type "profile". See this reference for a lists those fields and in which modes they actually contain data.


Special features

This section describes some special features about personalisation and its modes.

Table of contents: