Basic HTTP Authentication

Sometimes, you have to protect access to a complete site, e.g. during development of a new site to make sure that search engines or other third parties won't get access too early to something that is not meant for the public yet.

A common way of doing this is to configure the webserver to ask for some authentication before forwarding requests to Drupal. In such scenarios, DRD would normally have no chance to do its job because it would be blocked by that authentication wall. But we've covered that and you can configure authentication in your DRD either for all sites of a host, all sites of a core or just for individual domains. For each three of them you find a header section in their edit form:

You can define as many key/value pairs for each host, core and domain which will be added as header values for each request that DRD submits to the remote site. If the same key is defined more than once, then core values overwrite host vars and domain vars overwrite core vars. In other words, DRD uses the most specific a key/value pair for any given domain.

Back to authentication: The screenshot above shows an example on how you can specify the basic authentication for a specific domain. As you can see, the basic auth value is a hash, but you only may be aware of a username and password pair.

You could easily compute the hash with a little script, but an easier way is to navigate to that domain with your browser, enter the username and password when you get prompted for them and then open the browser console (often with Ctrl-Alt-C) and open the network tab. Reload the page and then select any one component in the list. You will then see a section with request headers and there you can "steal" the correct value for the authorization header.

The basic HTTP authentication request might contain, for example, a header field of the form Authorization: Basic <credentials>, where credentials is the base64 encoding of id (username) and password joined by a single colon (:).

For example, if the browser uses JohnSmith as the username and p@55w0rd as the password, then the field's value is the base64-encoding of JohnSmith:p@55w0rd, or Sm9oblNtaXRoOnBANTV3MHJk. Then the Authorization header will appear as:

Authorization: Basic Sm9oblNtaXRoOnBANTV3MHJk