Running tests on an application that requires authentication

Running tests on an application that requires authentication

You might need to monitor journeys located behind a login. There are two ways to ensure that your Datadog Browser tests can go through the login steps of your application to perform validation on post login pages:

You can also ensure your credentials are securely stored and obfuscated across the application using secured global variables.

Are you interested in testing applications sitting behind MFA? Visit the below section and send us feedback to help us work on the systems that matter the most to your teams.

Include the login steps in your recording

The first method is to record the steps that are needed to perform the login at the beginning of your browser tests: input your username, input your password, hit log in. You can then go on and start recording subsequent steps. At test execution, the browser test systematically executes the first login steps before going through the rest of the journey.

By default, the iframe/pop up of the recorder uses your own browser. If you start the recording already logged into your application, the iframe/pop up might directly display a post-login page, which prevents you from recording your login steps without logging out first.

To record your steps without logging out of your application, use the recorder’s incognito mode.

Opening a pop up in incognito mode allows you to start your test’s recording from the start URL set in your test configuration with a session completely isolated from your own browser’s main session and user data. The freshly opened incognito pop up ignores all your previous browser history including cookies and local data. You are automatically logged out from your account and can start recording your login steps as if you were visiting your website for the first time.

Note: Use the subtest feature to group your login steps into a single subtest that you can then reuse across any other browser tests that require a login.

SSO login

If your website uses SSO for login, input your application’s URL as the starting URL of your browser test. The test performs the required redirections as part of the first default Navigate to URL step.

Some SSO providers might detect Datadog’s browser tests as bots and prevent them from logging in, for example, by adding a reCAPTCHA. If that is your case, consider reaching out to your SSO provider to see if it is possible to turn off bot detection when identifying requests as coming from Synthetic browser tests (such as for a specific set of credentials or Synthetic tests specific headers) for testing purposes.

An alternative would be to use a non-SSO approach and leverage a regular username and password combination to go through login.

Multi-factor authentication

Datadog Synthetic Monitoring supports Time-based One Time Passwords (TOTP), a multi-factor authentication method that combines a secret key and the current time to generate a one-time password.

Browser tests can reproduce any actions a regular user take inside their browser. When setting up your test, record any multi-factor (including 2FA or TFA) authentication steps inside the browser.

Some MFA providers may detect Datadog’s browser tests as bots and prevent them from logging in, for instance, by adding a reCAPTCHA. In this case, contact your MFA provider to see if it is possible to turn off bot detection when identifying requests as coming from Synthetic browser tests (such as for a specific set of credentials or Synthetic tests specific headers).

If your MFA process involves steps performed outside of the browser (such as voice, text message, or opening a mobile application that does not leverage TOTP), consider reaching out to your MFA provider to ask if your MFA settings can be modified or if MFA can be turned off when identifying requests as coming from Synthetic browser tests (such as for a specific set of credentials or Synthetic tests specific headers) for testing purposes. Depending on the type of MFA leveraged by your application, JavaScript steps can help to work around that.

We are constantly adding features to help you record test scenarios more easily. Help us work on the MFA systems that matter the most to you by sending us feedback.

Leverage browser test configuration options

The second way to ensure that your Datadog Browser tests can login into your applications is to leverage one or several of the available browser test configurations. You can indeed decide to apply:

  • Specific headers
  • Cookies
  • Basic, Digest, or NTLM credentials

These configuration options are set at every test execution and apply to every step of your browser test at execution time, not recording time.

You can manually apply these configured headers, cookies, and credentials on the page you are recording from and then record steps your test performs post-login. By default, the browser test automatically passes through authentication with your specified headers, cookies, and/or credentials at execution time and then goes through all recorded steps.

Account security

Secure your authentication data

Store your credentials as global variables (for example, one global variable for username, another one for password) and set these variables as secure to obfuscate their values from anyone else who has access to your instance of Datadog.

Once you create the secure variables, you can then import these global variables into your browser tests and leverage them for your login steps.

Note: Although Datadog global variables are securely stored and encrypted, it is strongly recommended that you use an account dedicated to testing with dummy credentials as a general testing best practice.

Further Reading