Auto Login


Personalization module offers three methods you can use to automatically log in visitors who are returning to your site without requiring them to enter a login:

  • Auto-Login with Basic Authentication
  • Auto-Login with Cookies
  • Auto-Login by Profile

Auto-Login with Basic Authentication

Set the verifyBasicAuthentication property true in the /atg/userprofiling/ProfileRequestServlet:

Auto-Login with Cookies

set the sendProfileCookies property true in the /atg/userprofiling/CookieManager component:

If you use auto-login with cookies, you should not also use auto-login with Basic Authentication. Disable the auto-login feature for Basic Authentication by setting the following property in the /atg/userprofiling/ProfileRequestServlet:

Auto-Login by Profile

You can set up your site so that registered users can choose whether or not they want the site to log them in automatically. After a user registers on a site for the first time, his or her login information is stored in a user profile. You can provide a “Log me in automatically” option that users can choose on your Web site. If they choose this option, set the autoLogin property of the /atg/userprofiling/PropertyManager component of their user profile to true.

Once users choose auto-login, every time they visit the Web site, the Personalization module checks their user profile and, if the auto-login property is set to true, the PropertyManager component tells the ProfileRequestServlet to send out an auto-login cookie and allows the user to automatically access the site. To use this form of auto-login, you must therefore also set the sendProfileCookies property of the CookieManager component to true.

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.

By default : profileCookieMaxAge=-1 (cookies are not persistent)
Example : profileCookieMaxAge=604800 (presist cookie for a week- value is number of second)

Securing Cookies

To make user cookies more secure and prevent site visitors from changing their cookies (which could allow them to use someone else’s profile), the Personalization module includes a feature for checking profile ID cookies that it can use to validate the visitor’s cookie.

If you choose to send profile cookies (by setting sendProfileCookies to true), the Personalization module automatically sends two cookies, DYN_USER_ID and DYN_USER_CONFIRM. The DYN_USER_CONFIRM cookie is a hash of the user ID cookie. If the hashed DYN_USER_CONFIRM cookie does not match the user ID cookie, the Personalization module ignores the cookies and creates a new profile.

To change the secret key that the Personalization module uses to hash the user ID cookie, edit the following property of /atg/userprofiling/CookieManager:

Security Status

On some sites, you may want to require users to log in manually only if they access certain pages on the site. To do this, you can use a combination of auto-login and manual log in.

The securityStatus property of the Profile component is used to indicate the type of verification the user has passed through. When a user logs in (or is automatically logged in), the Personalization module sets the value of this property to an integer that indicates the login method used.

For example, if the user tries to access a restricted page, you can check the securityStatus value. If securityStatus indicates the user has already manually logged in, the restricted page is displayed; if securityStatus indicates the user was automatically logged in, the site prompts for a user name and password before displaying the page, to ensure that no unauthorized person can access the restricted content. The system then changes the value of securityStatus to indicate that the user has logged in manually, so future attempts to access restricted content during the session do not require re-entering the user name and password.

<dsp:valueof bean="/atg/userprofiling/Profile.securityStatus"/>

The following table lists the values of securityStatus and the login methods to which they correspond. Note that the default value is 0.

  • 0 : Anonymous login
  • 1 : Auto-login by URL parameter - By default this login method is disabled. You can enable it by setting the extractProfileFromURLParameter property of /atg/userprofiling/ProfileRequest to true.
  • 2 : Auto-login by cookie - By default this login method is disabled. You can enable it by setting the extractProfileFromCookieParameter property of /atg/userprofiling/ProfileRequest to true.
  • 3 : Login by http-(basic-authentication) - The user has provided a login and password, but it was provided to and verified by the Web server, not the Personalization module.
  • 4 : Explicit login or registration in the Personalization module - The user signed in or registered using a login form that invoked /atg/userprofiling/ProfileFormHandler.
  • 5 : Explicit login or registration in the Personalization module under https protocol. - Similar to 4, but login was through secure sockets layer (https protocol).
  • 6 : Certificate (not supported by ATG at this time).

securityStatus is a transient property by default, which means that it is not stored in the underlying database (for more information, see the ATG Repository Guide). It is also a property of type atg.repository.SessionEnumPropertyDescriptor, which means that its state is maintained in the user’s session rather than in the cache for the profile repository item. This behavior ensures that each visit to the Web site produces a unique securityStatus value, and that the securityStatus always expires when the session ends.

By default, security status is enabled. You can disable it by setting the enableSecurityStatus property of the /atg/userprofile/ProfileTools component to false.

In some cases you may want the security status to be reset for all users after server failover, requiring them to log in again. In other cases, it may be appropriate for your users’ security status to persist after failover. You can define this behavior through the failedOverSecurityStatus property in the /atg/userprofiling/ProfileSessionFailService component.

By default, the property is set to 3 (basic authentication only; users must log in to the Personalization module again). If you set the value to -1, the users’ existing security status will be the same after failover.

How to use :

We need to compare the value of Profile.securityStatus with PropertyManager.securityStatusLogin (/atg/userprofiling/PropertyManager).

If the value of securityStatus is less than the value of securityStatusLogin, the user did not log in manually, so a login form is displayed. If the value of securityStatus is greater than or equal to the value of securityStatusLogin, the user has already manually logged in, so the requested content is displayed.

  • PropertyManager.securityStatusLogin :
  • securityStatusAnonymous
  • securityStatusUrl
  • securityStatusCookie
  • securityStatusBasicAuth
  • securityStatusLogin
  • securityStatusSecureLogin
  • securityStatusCertificate

For example, the PropertyManager.securityStatusLogin property has a default value of 4, which is the value that Profile.securityStatus is set to if the user logs in manually under http protocol.

<dsp:droplet name="Compare">
  <dsp:param bean="Profile.securityStatus" name="obj1"/>
  <dsp:param bean="PropertyManager.securityStatusLogin" name="obj2"/>
  <dsp:oparam name="lessthan">
     <!-- send the user to the login form -->
     <dsp:include page="login_form.jsp"></dsp:include>
  <dsp:oparam name="default">
     <!-- allow the user to proceed to the protected content -->
     <dsp:include page="protected_content.jsp"></dsp:include>

No comments :