I recently spent some time investigating a client’s reports of unexpected behavior with the duration of browser sessions while testing an application on a test server. From time to time, they were required to login even while actively using an application. In this post, I’ll highlight the difference between an idle session timeout and an LTPA token expiration, which serve different purposes and, in the latter case, may cause frustration if not understood.
Most users are familiar with the concept of a browser session timing out if left idle for too long. In this case, websites will generally inform the user that a session has expired and require the user to login again in order to continue.
But users will generally not expect to be required to login again while actively using an application, so it’s important to understand why it might happen and what you can do about it.
Idle Session Timeout – Server
The Domino server document has a setting to define how long it will take for the session to be automatically logged out due to inactivity. This is configured on the server document:
Internet Protocols... > Domino Web Engine > Idle session time-out
The default is 30 minutes.
Idle Session Timeout – Application
There is also an application-level setting for the session timeout, which can be found on the
General tab of
LTPA Token Timeout
If single sign-on is configured to share the session between multiple servers, a Web Configuration document will define the SSO parameters.
The key setting in this case is the
Expiration (minutes) field on the
Basics tab of the document. This defines the lifespan of the LTPA token that is issued when the user logs in.
The important thing to understand is that this has nothing to do with how active or idle the session is.
This is a fixed length of time for which the key will be valid. Once it expires, the user will be prompted to login again. This can be very confusing to a user who is actively using the application!
Improving the Experience
There are a number of ways to implement controls to keep a session from timing out due to inactivity, but they will have no effect on the expiration of the LTPA token.
In order to prevent users from being frustrated with frequent logouts, some very smart people including Per Lausten and Sean Cull, have written about this in years past and have recommended setting the token expiration to a much larger number in order to prevent unexpected behavior. The idle session timeout can still do it’s job dealing with inactive sessions (and you as a developer can programmatically work to keep them alive if desired).
I’m familiar with setting XSP properties in xsp.properties at the application or server level and I’ve used
tags to do the same within a theme, but I did not realize until recently that you can also set these properties at the XPage level to override the broader settings on a page-by-page basis.
Select the root
tag for the page and go to
All Properties in the Properties view. Under the
data subtab, click on
properties and click the plus (
+) button to add a property.
This adds a new parameter and defaults the name attribute to
param and the value attribute to
val. In the source, it adds an
xp:this.properties tag containing an
Let’s see this in action with a few examples.
Here’s the first fiew lines of a brand new, unmodified XPage on my test server. The application leaves the server defaults for the HTML doctype and character set (although the latter is not visible in this output).
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html lang="en"> <head> <title></title>
If you want to add a
meta tag to the page that displays the doctype and character set, you can add the
xsp.html.meta.contenttype property to the page and set its value to true.
You can also override the HTML doctype and character set for the page with additional properties. (Click on the picture to enlarge.)
Here’s the updated first few lines of output, including the
meta tag and reflecting the updated doctype and character set:
<!DOCTYPE html> <html lang="en"> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <title></title>
There are many more properties that can be modified at the page level (though not all of them). If you have the XPages Portable Command Guide, you can find them all described in depth there (The book covers through 8.5.3. Sven Hasselbach has a good post on some new properties that were added in Notes 9.)
It appears that you can similarly modify properties at the custom control level, but I have not tested the effectiveness or how conflicts are handled.
Allow zero rows in repeat controls setting in XSP Properties can be used to cause a Repeat control not to display any rows, giving you the ability to compute the row count as desired, even when there is data that would otherwise have been displayed. In this post, I’ll show how to update the setting and describe its effect.
In Notes 9, you can find the XSP properties under Application Configuration in the Applications view of Domino Designer.
This UI gives you a nicer front end to modify a number of values in the xsp.properties file, which contains a lot of configuration information for the application.
There are 4 tabs, 3 of which contain several properties that you can modify and the fourth tab which displays the full source of the properties file.
There are many, many properties that can be set in the file, but there are only a few specified by default. The rest are treated as default values when not otherwise specified.
As you change properties in the UI, they will be added to the source.
Allow zero rows in repeat controls
Allow zero rows in repeat controls setting on the
Page Generation tab is not selected (i.e. false) by default.
The effect is that if you have a Repeat control where the rows property is computed to 0, it will revert to the default row count of 30.
If you select that option, it adds this line to xsp.properties:
With this setting, you can compute a Repeat control’s
row count to 0 and it will not show any rows. This effectively hides it from the UI, but still loads the repeat control into the JSF component tree so it can be modified programmatically, if necessary.
The XPages Portable Command Guide says that this property applies to View Panel, Data Table, and Repeat controls.
It works as expected with a Repeat control, but did not work properly with a View Panel in my testing (with Notes 9).
With the property set to false, a View Panel with the rows property set to 0 would show 30 rows. With the property set to true, the View Panel throws a
divide by zero error.