Add a User Session to an Audit

User Sessions

User Sessions allow an audit to be configured with a username and password to access protected content. User sessions force the audit to log into the web site before visiting any pages, including the starting page(s) of the audit. Configuring a User Session is similar to configuring Actions in audits or web user journeys.

Simulating the Login Process

Follow these instructions to add a user session for an audit. Since there are many ways to implement logins (basic authentication, two-factor authentication, VPN, and more), these instructions are very general (see Create or Edit a Web User Journey for more details on setting up Actions):

• Create a new audit and click to open the Advanced Options panel.
• Scroll to the bottom of the page and click on User Sessions to open a process that allows you to add steps.
• Configure the steps to perform the login (see Create or Edit a Web User Journey).

The steps to perform a login are called Actions and they are configured just the same as any other Actions in audits or web user journeys.

The first Action for setting up a login is always NavTo. Enter the URL of the page where the login functionality is.

Example Configurations

Example 1: Username and Password

A common login process involves a form with username and password fields and a submit button. A typical User Session configuration would look like the following, based on the page found at http://jpstyle.us/user/login:

• Step 1, access the login page
  • Type: Navigate To
    URL = http://jpstyle.us/user/login
• Step 2, type in the username
  • Type: Input
    Value = student
    Identifier = edit-name
• Step 3, type in the password
  • Type: Masked Input
    Value = trainme
    Identifier = edit-pass
• Step 4, click the submit button
  • Type: Click
    Identifier = edit-submit

Example 2: Username, Password and Security Question on Separate Pages

Another common login process involves an additional step where the server responds to the username with secret information, such as an image, and a chance to type in a password. If the server delivers a predictable security response (because it was configured by the user) rather a randomly generated response, a configuration similar to below would likely work (this is simply an example with fictitious credentials):

• Step 1, access the login page
  • Type: Navigate To
    URL: http://mybank.com
• Step 2, enter the account number
  • Type: Input
    Value: 1234567890
    Identifier: login_acct_number
• Step 3, click the Login button
  • Type: Click
    Identifier: login_acct_submit
• Step 4, type in the password
  • Type: Input
    Value: myp@ssw0rd
    Identifier: login_acct_password
• Step 5, click the Continue button
  • Type: Click
    Identifier: login_acct_continue
• Step 6, answer a security question
  • Type: Input
    Value: John
    Identifier: security_question_1
    (note, this step assumes a predictable security question, such "What is your father's name?")
• Step 7, click the Continue button
  • Type: Click
    Identifier: login_submit

Other security processes might include random security questions or other secure methods. In cases such as these, contact your Data Governance Consultant for help.