---
title: Handle sites with authentication
source: https://docs.newrelic.com/docs/synthetics/synthetic-monitoring/using-monitors/handle-sites-authentication
---

Synthetic monitoring supports a variety of authentication mechanisms. Depending on the type of monitor you choose, this includes Basic, Digest, NTLM, and NTLMv2.

## Supported authentication by monitor type [#supported_authentication]

Support for various [monitor types](https://docs.newrelic.com/docs/synthetics/new-relic-synthetics/using-monitors/add-edit-monitors#types-monitors) may depend on your site configuration.

| **Synthetic monitor type** | Basic | Digest | [NTLM](#tip) | [NTLMv2](#tip) |
| -------------------------- | ----- | ------ | ------------ | -------------- |
| Ping                       | ✓     |        |              |                |
| Simple browser             | ✓     | ✓      | ✓            | ✓              |
| Scripted browser           | ✓     | ✓      | ✓            | ✓              |
| API test                   | ✓     |        |              |                |

> #### 💡 TIP
>
> For NTLM and NTLMv2, synthetic monitoring uses a Chrome browser in a Linux environment, so your configuration must be compatible with this client-side environment. It must also allow URI-encoded credentials.

## Provide authentication credentials [#url_encoding]

Monitors provide authentication credentials by encoding them in the requested URL, such as `http(s)://username:password@site.com`. To do so, use the `encodeURIComponent('string')` JavaScript function in your script. For example:

```js
var username = encodeURIComponent("username");
var password = encodeURIComponent("password");
var url = "https://" + username + ":" + password + "@site.com";
```

To encode values for a ping or simple browser monitors, follow [these instructions](https://www.w3schools.com/tags/ref_urlencode.ASP).

The full URL `http(s)://username:password@site.com` will be recorded as plain text in the corresponding synthetic's check data. The URL will be visible when viewing results for this monitor.

## Code examples [#code_example]

Here are code examples for some monitor types:

### Scripted browser

```js
$browser.get("https://username:password@site.com").then(function () {
  $browser.takeScreenshot();
});
```

```js
$browser.get("https://username@domain.com:password@site.com").then(function () {
  $browser.takeScreenshot();
});
```

### API test

```js
$http.get("https://username:password@site.com", function (err, resp, body) {
  console.log(err, resp, body);
});
```

## Troubleshoot NTLM authentication issues

You can check if New Relic will be able to properly authenticate against your NTLM endpoint using [curl](https://curl.haxx.se) or with a scripted API monitor. You must use a host or location with access to your endpoint.

### curl

To do this, run the following command, with the URL replaced by the endpoint you want to test:

```sh
curl -v --ntlm http://example.com
```

In the output from that command you should see the following `response` header telling you the server is offering NTLM over HTTP as a valid authentication mechanism:

```
WWW-Authenticate: NTLM
```

### Scripted API Monitor

Create a new API test monitor and assign it to a location with access to your endpoint. Replace the URL and validate the following script, which will print all response headers to the script log:

```js
$http.get("https://www.newrelic.com",
  {
    followRedirect: false,
  },
  // Callback
  function (err, response, body) {
    console.log(response.headers);
  }
);
```

Confirm that the WWW-Authenticate response header includes NTLM.

### Redirects

NTLM authentication failures may be caused by `$browser.get` calls that result in a redirect. Check the response code for your request in the Timeline view in your monitor results. If the request is being redirected you may need to use the redirection location as the URL in the initial `$browser.get` call instead.