> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vikingqa.io/llms.txt
> Use this file to discover all available pages before exploring further.

# HTTP sign-in

> Let the agent's browser open a site that asks for a username and password in a browser pop-up.

## 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.

> [!NOTE]
>
> 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.

| You enter | Used on |
| - | - |
| `https://staging.example.com` | Every page of the site |
| `https://staging.example.com/admin` | `/admin` and the pages under it, such as `/admin/users`. Not `/administrator` |

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](https://docs.vikingqa.io/security/data-protection.md#credentials).

## 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.

| The agent says | What it means | What to do |
| - | - | - |
| HTTP sign-in to `<address>` was refused; the environment's credentials are probably wrong. | The site did not accept the saved username and password. | Edit the sign-in with the correct username and password, then send your message again. |
| `<address>` asks for a username and password in a browser sign-in pop-up, and this environment has no HTTP sign-in saved for it. | No sign-in in this environment covers that page. | Add a sign-in for the site, or for that page. Check that you are in the correct environment tab. |
| The browser could not sign in to `<address>`: vikingQA could not set up this environment's HTTP sign-in just now. | A temporary problem on our side. | Send your message again in a moment. If it continues, contact us. |

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`](https://playwright.dev/docs/api/class-testoptions#test-options-http-credentials)
  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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.