Skip to main content

​
When you need this

Some sites ask for a username and password in a small browser pop-up before any page loads. This is called HTTP Basic Auth, and teams often use it to hide a staging site. The agent cannot see that pop-up and cannot type into it. Save the username and password once, and the agent’s browser signs in by itself. No pop-up appears.
A login form on the page itself (fields and a Sign in button) is not HTTP sign-in. The agent fills in a form like that the same way a person does.

​
Add a sign-in

1

Open the settings

In your project’s settings, under Test environment, open HTTP sign-in.
2

Choose the environment

Sign-ins belong to an environment. Pick the tab of the environment whose site asks for the password. Each environment has its own sign-ins, so a staging password is never used on another environment’s site.
3

Add the site

Select Add HTTP sign-in. Enter the site address, then the username and the password, and select Add sign-in.
The password is encrypted and is never shown again, not even to you. The list shows each address, its username, and who last set the password and when.

​
Which pages a sign-in covers

The address you enter decides where the sign-in is used. As you type, the dialog tells you which pages it will cover. If the whole site asks for the password, enter the site address. A sign-in saved for one page does not cover the rest of the site, so the site’s other pages, styles and scripts would still ask for the password. You can save a sign-in for the whole site and another for one part of it, for example https://staging.example.com and https://staging.example.com/admin. The agent’s browser then uses the most specific one: the /admin sign-in on /admin and the pages under it, and the site sign-in everywhere else.

​
Address rules

  • https:// only. On plain http://, the browser would send the password without encryption, so http:// addresses are refused.
  • You can leave out https://. staging.example.com is read as https://staging.example.com.
  • You can paste a full page address. Anything after ? or # is ignored.
  • One site per sign-in. Wildcards such as https://*.example.com are not supported. Add each subdomain on its own.
  • No username or password in the address. Enter https://staging.example.com, not https://user:pass@staging.example.com. Put them in their own fields.
  • One sign-in per address in an environment. To change one, edit it.

​
Change or remove a sign-in

Open the ⋯ menu on the sign-in’s row.
  • Edit changes the username or the password. To change only the username, leave the password empty and the saved one is kept. The address cannot change. To use a different address, remove the sign-in and add a new one.
  • Remove deletes the sign-in and its password at once. It cannot be restored. To add it back, enter the password again.
A change is used from the next message you send the agent.

​
What the agent’s browser does with it

  • It sends the username and password only to the address you saved: the same https://, the same host and the same port, and only the pages under the path if you entered one. A different subdomain, a third-party script or a redirect to another site never receives them.
  • It adds the sign-in to each request before the site asks for it. Because of this, the pop-up never appears, also in new tabs and windows that the agent or the page opens.
  • If a request already carries its own Authorization header, for example your site’s API token, the browser leaves it unchanged.
  • The agent never receives the password. The sign-in is also removed from what the agent reads, including pages that show the request headers back. This removal works on text only. If a page shows the password in a screenshot, the agent can see it. Use a sign-in that protects test environments only. For how we store and protect credentials, see Security and data protection.

​
When the agent tells you about it

The agent cannot see the pop-up, so when sign-in fails it tells you what happened instead. It does not try again, because a retry fails the same way. If you saved a sign-in for one page and the agent reports a page outside it, replace that sign-in with one for the whole site.

​
Where it does not apply

  • Your own Playwright tests. A test run uses your repository’s playwright.config. Set httpCredentials there. vikingQA does not give these sign-ins to a test run.
  • The browser extension. You are at the keyboard, so you answer the pop-up yourself.
  • Other sign-in types. Only HTTP Basic Auth is supported. Sites that use Digest, NTLM or Kerberos (Negotiate) sign-in, and proxies that ask for a password, are not.