Khoros Global Support Home Start a conversation Sign in
Start a conversation
  1. Khoros Aurora
  2. Troubleshooting
  3. Articles

Troubleshoot HTTP 401 Basic Auth on a Khoros Aurora Stage Community

Table of contents

Overview

A Khoros Aurora stage community can be protected by HT-Access, also known as HTTP Basic Authentication. When this protection is enabled, the web server checks for an HT-Access username and password before the Aurora community page loads. If the request does not include valid HT-Access credentials, the expected response is usually HTTP 401 Unauthorized with a WWW-Authenticate: Basic response header.

This can look like a site outage if you expected the stage community to load directly. It can also be confused with an IP allowlisting request. The important distinction is that HT-Access is a credential challenge, while IP allowlisting is a source-network rule. They are separate access controls, and the correct next step depends on which control is blocking the request.

Use this article when a stage community URL:

  • shows a browser username/password prompt before the community loads,
  • returns HTTP 401 before the Aurora sign-in page appears,
  • returns a WWW-Authenticate: Basic header, or
  • is being investigated as a possible IP allowlisting issue but may actually require HT-Access credentials.

Prerequisites

  • The exact stage community URL you are trying to access, for example https://<stage-community-hostname>/.
  • HT-Access credentials for that specific stage community, or the ability to request them from your community administrator or Khoros Support.
  • For command-line testing, terminal access from the same machine or network path that is failing.

Note: HT-Access credentials are not the same as your Aurora community username and password. HT-Access is checked before the Aurora application sign-in flow.

Solution

Follow the checks in order. The goal is to determine whether the request is being stopped by the HT-Access credential gate, by a different network or proxy issue, or by a community-specific access rule.

Confirm that the response is a Basic Auth challenge

  1. From the affected machine or network, send a header-only request without credentials: 
    curl -I 'https://<stage-community-hostname>/'
  2. Review the response status and headers. A Basic Auth challenge usually looks similar to this: 
    HTTP/2 401
www-authenticate: Basic
  3. If you see HTTP 401 with WWW-Authenticate: Basic, treat the result as an authentication challenge. This means the server is asking for HT-Access credentials before it will serve the stage community.

Why this works: A Basic Auth protected resource advertises the required authentication method in the WWW-Authenticate header. Checking the headers separates an expected credential challenge from unrelated failures such as DNS errors, TLS errors, proxy blocks, or timeouts.

What can go wrong: Testing only in a browser can hide the actual HTTP status behind a generic login prompt or browser error page. The curl -I check shows the status and headers directly.

Access the stage community with HT-Access credentials

  1. If you have the HT-Access username and password, open the stage community URL in your browser.
  2. When the browser prompts for credentials, enter the HT-Access username and password. After this gate succeeds, the Aurora community page can load. Depending on the community, you may still need to sign in with your Aurora account after the page loads.
  3. If you need to test from a terminal, send the same request with credentials: 
    curl -I -u '<htaccess_username>:<htaccess_password>' 'https://<stage-community-hostname>/'
  4. If your password contains shell-special characters, keep the full <username>:<password> value inside quotes as shown above.
  5. If a tool requires credentials in the URL instead of a prompt or an Authorization header, use URL-encoded credentials: 
    https://<url_encoded_htaccess_username>:<url_encoded_htaccess_password>@<stage-community-hostname>/

Tip: URL-encoding means replacing reserved characters with percent codes when those characters are used as data inside a URL. Common examples in credentials include @ as %40, : as %3A, # as %23, % as %25, and a space as %20. If you are unsure whether a credential is encoded correctly, use the browser prompt or the curl -u format instead of putting credentials in the URL.

Warning: Prefer the browser prompt or curl -u method when possible. Do not paste real HT-Access credentials into shared documentation, screenshots, ticket text, or chat messages.

Interpret the result

Result What it means What to do next
HTTP 401 with WWW-Authenticate: Basic when no credentials are supplied The stage community is challenging the request for HT-Access credentials. Use the correct HT-Access credentials for that stage community.
HTTP 200 or a redirect such as HTTP 301 / HTTP 302 after credentials are supplied The HT-Access gate accepted the credentials. Redirects can be normal if the community sends the request to a landing page, category page, locale path, or sign-in flow. Continue loading the site. If the Aurora application later shows a separate sign-in page, sign in with your Aurora user account.
HTTP 401 still appears after credentials are supplied The credentials may be incorrect, no longer current, copied with an extra space, or intended for a different stage community. Verify the exact stage URL and request current HT-Access credentials from your community administrator or Khoros Support.
Timeout, DNS failure, TLS/certificate error, proxy error, or no response The request may not be reaching the Basic Auth challenge. The blocker may be local DNS, proxy, firewall, VPN, or another network path issue. Test from another network if possible and collect the exact error, timestamp, and command output before contacting Support.
HTTP 403 or another non-401 status The response is not the standard missing-credentials Basic Auth challenge. Collect the status, response headers, URL, and timestamp. Support may need to verify whether a community-specific access rule is involved.

Understand what IP allowlisting does and does not solve

Do not use the Aurora outbound static IP list to troubleshoot inbound browser access to a community URL. The outbound static IPs are for requests that originate from Community and go to external services, such as webhooks, SSO-related calls, custom backend integrations, and server-side HTTP calls. They are not the IP addresses customers should allowlist for inbound access to the community. For the outbound list and its scope, see Aurora Community static IP addresses.

HT-Access and IP allowlisting answer different questions:

  • HT-Access asks: “Did this request provide a valid username and password for the protected stage site?”
  • IP allowlisting asks: “Is this request coming from an allowed source IP address or network?”

A stage community can be configured with HT-Access, IP-based rules, or both. Because the configuration is community-specific, do not assume that adding a source IP will remove a Basic Auth challenge. First confirm the actual response. If the response is HTTP 401 with WWW-Authenticate: Basic, the immediate blocker is the HT-Access credential challenge.

What to send to Support if access still fails

Contact Khoros Support if you do not have the HT-Access credentials for your stage community, if valid credentials still return HTTP 401, or if the failure looks like a network or access-rule issue instead of a Basic Auth challenge.

Include the following details so Support can distinguish authentication, IP allowlisting, and network-path issues without another round of questions:

  • Stage community URL, for example https://<stage-community-hostname>/.
  • Whether the same issue happens in a browser, from a terminal, or both.
  • The command you ran, with credentials removed or replaced by placeholders.
  • The response status and headers from: 
    curl -I 'https://<stage-community-hostname>/'

curl -I -u '<htaccess_username>:<htaccess_password>' 'https://<stage-community-hostname>/'
  • The exact timestamp of the failed test, including time zone.
  • The public source IP address or addresses of the affected machine or network, especially if you believe an inbound source-IP rule may be involved.
  • A screenshot of the browser prompt or error page, with credentials and personal data hidden.
  • Whether the production community URL behaves differently from the stage URL.

Credential handling guidance

  • Use https:// for stage community access. Basic Auth credentials must not be sent over an unencrypted connection.
  • Do not include real HT-Access credentials in screenshots, logs, copied command output, documentation, or ticket comments.
  • If you must show a command to another person, replace the credential value with placeholders such as <htaccess_username> and <htaccess_password>.
  • If credentials stop working, request a current credential check instead of reusing values from an old ticket, chat, browser history, or saved note.
Choose files or drag and drop files
ai_initiated
atlas_studio
kb_automation
Was this article helpful?
Yes
No

  1. Priyanka Bhotika

  2. Posted

Comments