Logon URL

Log a registered user on to a store or site.

Use this URL with SSL (Secure Sockets Layer) to ensure that the customer's logon password and personal information are encrypted. To do so, type the URL with the HTTPS secure protocol.

Warning: Only use HTTP POST with this URL. By using HTTP GET, passwords can be logged in the browser history, or in web server logs.

URL structure

The fully qualified name of your HCL Commerce Server and the configuration path

Parameter values

Sets or resets the preferred language during the session; the supported languages for a store are found in the STORELANG table
The URL to be called when the command completes successfully
The reference number of the store the user is logging on to
The registered user's logon ID
The registered user's password
The URL that is called if the command fails to complete
Optional. Specifies to remember the user after they close the browser. This parameter works only if a persistent session is enabled.

Example 1

The following example logs the customer with the logon ID henry and the password h48smith on to the store with reference number 10101, then displays the store home page.



The following checks are done to ensure that the user is allowed to log on:
  1. Verify that the user's account is not disabled. (Not done if LDAP mode is used.)
  2. Verify that logon is allowed. The account lockout policy specifies how much time must elapse after an incorrect password attempt, before a subsequent logon attempt is allowed.
  3. Verify that the password specified by the user is correct.
  4. Verify that the user's account is approved.
  5. Verify that none of the user's ancestor organizations are locked.
  6. Verify that the user has a role in the current store's organization.
If valid credentials are specified, and LDAP mode is used, the default roles that are specified in MemberRegistrationAttributes.xml are assigned to the user.
Regardless of whether valid credentials were specified and LDAP mode is not used, the AccountLockoutPolicyCmd task command is called to update policy account information for the user:
  • Account lockout policy:
    • USERREG.PASSWORDRETRIES is incremented on a bad password attempt.
    • If there are too many retries with incorrect passwords, the user account gets disabled, by setting USERREG.STATUS to 0.
  • Policy password policy:
    • If the password is too old, the password is changed to the expired state, by setting USERREG.PASSWORDEXPIRED to 1.
  • The AccountLockoutPolicyCmd task command does not do anything, if LDAP is used.
After successful logon, the following steps are also performed:
  1. The user's resources are migrated from the previous guest user if applicable.
  2. The command context is updated to the authenticated user's identity.
  3. If the password invalidation feature is enabled, and the password is in the expired state, and LDAP mode is not used, the user is directed to the ChangePassword view.
  4. If the logon took place after the login timeout feature ended the session, the user is directed to the URL that is originally specified when the login timeout took place.
The detailed behavior flow is as follows:
  • Calls the VerifyCredentialsCmd task command, which calls one of the following tasks:

    This flow ensures that the customer's logon ID and password are correct.

  • Calls the following tasks:
    • AccountLockoutPolicyCmd
    • AuthenticationPolicyCmd
    • MigrateUserEntriesCmd (This task must always be defined. There is a default implementation.)
      • By default, this command does not merge the shopping cart for the guest and registered users. You can configure the command to merge the cart by completing one of the following tasks:
        • Setting MemberSubSystem/MergeCartsAtAuthentication/enabled in the wc-server.xml to true
        • Setting the mergeCart parameter in the request properties of the command to true.
  • Checks whether the password expired and if it has, redirects to the ChangePassword view.
  • If any of the ancestral organizations to which a customer or administrative user for a store belong are locked, they cannot log on to the store.
  • With the Logon command, users logon on a per-store basis, and not a per-site basis. If a user does not play a role in a store's organization or any of its ancestral organizations, WebSphere Commerce does not allow the user to log on to the store.
  • If a user's registration approval status is pending approval, HCL Commerce does not allow that user to log on to the store.
To enable concurrent logon, see Enabling multiple logon support for the same user.To understand the default behavior, consider this scenario where concurrent logon is not supported:Two users at a company regularly share an account at a store. Suppose that the first user is on the store's payment page, and just before they submit their order, the second user logs in. The following events are the full series of events:
  1. Browser one ... User 1 logs in as user xyz; adds an item to the shopping cart.
  2. Browser two ... User 2 logs in as user xyz as well, and goes to the shopping cart page and then proceeds to checkout.
  3. Browser one ... User 1 clicks checkout, but is informed that they are logged off.
  4. Browser two ... User 2 completes the checkout process, as normal.
Another scenario is when businesses use a common user ID for their employees to shop at a B2B store. Either only one user should use the common user ID at a time, or each user should be set up with their own user ID. Otherwise, one of the users are likely not complete their transactions.
Note: If the password for a user is NULL in the database, the password must be reset when the user logs on. The password for the user is reset automatically regardless of the password that the user entered. An email is then sent to the user with a temporary password that the user can use to log on and set their user password. You can disable the automatic reset when the password is null at logon by disabling the following configurable property in the instance configuration file:
This property is enabled by default when the foundation feature is enabled. If you disable this property, a user must enter their challenge answer to reset the null password. Then, the user is issued a temporary password to log on and set their new user password.

You can configure the password reset functionality to issue validation codes to users instead of issuing temporary passwords. For more information, see Configuring Reset Password to use long validation codes.

Exception conditions

The error handler, ECConstants.EC_ERROR_CODE, captures the error code, which can be one of the following codes.
Explanation Error Code Value
Missing logon ID ECSecurityConstants.ERR_MISSING_LOGONID (2000)
Invalid logon ID ECSecurityConstants.ERR_INVALID_LOGONID (2010)
Missing password ECSecurityConstants.ERR_MISSING_PASSWORD (2020)
Invalid password ECSecurityConstants.ERR_INVALID_PASSWORD (2030)
Account is disabled ECSecurityConstants.ERR_DISABLED_ACCOUNT (2110)
HCL Commerce Version or laterAccount is locked out ECSecurityConstants.ERR_LOCKED_OUT_ACCOUNT(2490)
Password is too long or too short ECSecurityConstants.ERR_LENGTH_PASSWORD (2120)
Logon attempt took place too soon after previous failed attempt. ECSecurityConstants.ERR_LOGON_NOT_ALLOWED (2300)
One of your ancestral organizations is locked. ECSecurityConstants.ERR_PARENT_ORG_LOCKED (2400)
You do not play a role in the store's organization or any of its ancestors. ECSecurityConstants.ERR_NOT_REGISTERED_CUSTOMER (2410)
Your status is in pending approval state. You are not allowed to log on unless in approved stated. ECSecurityConstants.ERR_USER_IN_PENDING_APPROVAL (2420)