Logging into your app

Many testing scenarios require logging into an application before validating its functionality. In mabl, you can automate logins by recording steps in the Trainer. When these tests run in the cloud, each one starts with a fresh instance, so by default every test that validates a logged-in interaction authenticates on its own. Session data, such as cookies or cache, doesn’t carry over between tests in the same plan unless the login flow is set to share its browser state.

In mabl, you can use flows to simplify this process: train the login for your app once and reuse it across other tests that require the same type of login. Login flows help you add test coverage faster and reduce the need to maintain login steps separately for every test.

This article outlines best practices for creating and managing login flows in your mabl tests:

• Use test credentials
• Identify an approach for credentials
• Establish naming conventions
• Reuse a login across a plan run
• Limitations to automating logins

Example of a login flow in the mabl Trainer

Use test credentials

mabl stores your data securely, encrypting credentials with a workspace-specific encryption key. To further ensure that your applications are secure, we recommend the following:

• Create test credentials in your application to use for your mabl tests
• Avoid using credentials that reveal personally identifiable information in your mabl tests

Identify an approach for credentials

The primary way to log into your application is with mabl credentials. mabl credentials are a special class of variables that are configured at the workspace level and passed in at run time.

We recommend creating login flows with mabl credentials for the following reasons:

• Workspace owners can assign user roles to manage access to mabl credentials, including the ability to restrict access to specific users with resource groups.
• mabl credentials are not readily visible in your flows and tests.
• mabl credentials have an extra layer of encryption within mabl.
• You can save mabl credentials as cloud credentials for extra security.

Environment-specific credentials

mabl does not support assigning environment-specific credentials. If a plan requires different login credentials to run in different environments, consider substituting mabl credentials with environment variables as a workaround. The drawback of this approach is that you cannot currently use resource groups to restrict access to environment variables.

If this limitation impacts your workflow, please let us know in the mabl Product Portal.

Establish naming conventions for login flows

Establishing a naming convention for login flows makes it easier for other members of your team to reuse flows and helps you avoid doubling your efforts.

Helpful pieces of information may include user role and the application. For example:

• User login - main app
• Admin login
• Employee login - HR portal

Reuse a login across a plan run

By default, every test in a cloud plan run signs in for itself. To sign in once and let the rest of the plan run start from that session, turn on Persist browser state after flow execution for the login flow. The first test to finish the flow saves the browser state it produced, and later tests in the same plan run that use the same application and credentials start from it.

For the full setup, including how to order the plan so the login runs first, see reuse a signed-in session across a plan run.

Limitations to automating logins

Some sign-in methods can't be recorded and replayed the way a username-and-password login can. The following sections cover each one and what to do instead.

Testing apps with CAPTCHA

mabl can't get past CAPTCHA or reCAPTCHA on any login page. To test a login that shows one, have your test environment skip the CAPTCHA for requests that carry a header only your tests send, then add that header to your tests with custom HTTP headers.

Testing apps with SSO login

Apps that sign in through an identity provider can be tested in mabl as long as the identity provider shows a login page you can record.

If the login page never appears in the Trainer and you're automatically logged in, it could be due to your enterprise network sending system-level credentials to the app through SSO headers. In this case, turn on Block single sign-on under browser overrides in the Desktop App so that you can record the login. mabl cloud runs start in a clean browser session without automatically logging in, so the test needs a recorded login to pass.

Testing apps with Windows-integrated authentication

Apps that sign users in with their Windows session, through NTLM or Kerberos, can't be tested in mabl cloud runs. The mabl cloud browser has no Windows session and no connection to your domain, so the sign-in can't complete. Running tests over mabl Link or allowlisting mabl's IP addresses doesn't change this.

To check whether an app, or one component of it, uses Windows-integrated authentication, make an API request to its URL and look at the response. A 401 response with a WWW-Authenticate header that names NTLM or Negotiate confirms it.

There are two ways to test the app anyway. Both require a change in the test environments on your side. Your team can add a rule to the app, or to the web server in front of it, that treats any request carrying a secret header as signed in as a test user. mabl then sends that header on every request with custom HTTP headers. Or your team can put a username-and-password login in front of the component and let the app authorize the Windows-authenticated backend after that.

Testing apps with social logins

Social identity providers such as Google, Apple, Facebook, LinkedIn, and GitHub use anti-automation measures such as CAPTCHA and reCAPTCHA, which mabl can't get past. To test an app that signs in through one of them, expose another way to log in on your test environments:

• Using username/password login instead
• Exposing special login tooling in your testing environments for automation users
• Using provider supplied tooling for testing automation, such as Service Accounts + Google IAP