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.
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: cookies, local data, etc. 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.
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 (for example, for a specific set of credentials, Synthetic tests specific headers, etc.) 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.
Browser tests can reproduce any actions a regular user can take inside their Chrome browser. If you perform the multi-factor (or 2FA, or TFA) authentication step inside of a Chrome browser, you can record it when setting up your browser test. Some MFA providers might however 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 MFA provider to see if it is possible to turn off bot detection when identifying requests as coming from Synthetic browser tests (for example, for a specific set of credentials, Synthetic tests specific headers, etc.) for testing purposes.
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:
These are set at every test execution and consequently allow you to start the recording of your steps directly post login.
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.