You can configure many aspects of whether and how the Personalization module sends profile cookies using the CookieManager component (/atg/userprofiling/CookieManager). The CookieManager has the following properties:

If present, this defines the value of the domain field that is sent for profile cookies. (Default null)

Comment of the cookie used to carry the user ID, if cookies are in use. (Default null)

If present, this defines the value of the maximum age of the cookie, in seconds. A value of -1 indicates that there is no maximum age, making cookies non-persistent. (Default -1)

If present, this defines the value of the path field that will be sent for profile cookies. (Default /)

If true, cookies will include the secure field, which indicates to the browser that cookies should only be sent using a secure protocol, such as HTTPS or SSL. (Default false.) Note that, depending on the browser, this setting could prevent visitors from using the auto-login feature to access the site.

A component of a class that implements the atg.userprofiling.HashInitializer interface. (Default is /atg/userprofiling/HashInitializer.) This component is responsible for generating the hash key used for hashing user ID cookies. See Securing Cookies for more information.

Sets the hash key to use for hashing user ID cookies. If this property is set, its value is used for the hash key rather than a value generated by the HashInitializer component. Note that setting the key explicitly is not as secure as using a randomly generated key. See Securing Cookies for more information.

Using Persistent Cookies

By default, the cookies that the Personalization module sends are temporary; they expire when the user exits the browser. To enable auto-login or persistent anonymous profiles, you must configure the /atg/userprofiling/CookieManager component to use persistent cookies.

The profileCookieMaxAge property of the CookieManager component controls cookie persistence. This property sets the number of seconds from the time the profile cookie is sent until it expires. If you set the property to -1 (the default), cookies are not persistent.

For example, suppose you enable auto-login, but you want the user to log in manually after a week. You would set profileCookieMaxAge to the number of seconds in a week:

Securing Cookies

If you enable profile cookies (by setting the CookieManager component’s sendProfileCookies property to true), the application sends two cookies, DYN_USER_ID and DYN_USER_CONFIRM. The DYN_USER_CONFIRM cookie is a hash of the DYN_USER_ID cookie.

The purpose of using two cookies rather than one is to protect against a customer gaining access to another user’s profile by modifying the DYN_USER_ID cookie. The user profile associated with DYN_USER_ID is used only if it matches the hashed value in DYN_USER_CONFIRM. If the cookies don’t match, a new profile is created instead.

The cookieHashInitializer property of the CookieManager specifies the component responsible for generating and maintaining a unique hash key for your application. By default, this property is set to /atg/userprofiling/HashInitializer. This component, which is of class atg.userprofiling.HashInitializerImpl, is configured by default to perform an HmacMD5 hash of a randomly generated 8-byte String.

You can specify a different hashing algorithm by changing the value of the hashAlgorithm property of the HashInitializer component to any algorithm supported by the javax.crypto.KeyGenerator class. Valid values include:

Note you may also need to change the value of the textSize property to specify a byte-array size that is appropriate for the algorithm you use.

As an alternative to randomly generating a hash key, you can explicitly specify the hash key by setting the cookieHashKey property of the CookieManager. If this property is set, its value is used for the hash key rather than a value generated by the HashInitializer component. Note, however, that setting cookieHashKey is not recommended, because using a randomly generated hash key is more secure. However, this property is provided for compatibility with older ATG releases, to avoid breaking application behavior that is dependent on an existing setting.