Identify the exact domain and preview folder, save the current .htaccess file and confirm HTTPS works. Consider whether automated callbacks, certificate validation or public assets must remain outside the protected path.

1. Open Hosting Features > Htaccess, select the domain and choose Login.
2. Create or select the configuration for the intended directory, then open its pencil/edit action.
3. Add at least one htpasswd User with a strong unique password. Do this before enabling protection so an empty user list does not lock out every visitor.
4. Open the key/password-protection control, choose Enabled and update.
5. Test the preview URL in a fresh private browser session. Confirm a challenge appears, approved credentials work and an unrelated public directory remains accessible.

The protected resources should require the directory credentials over HTTPS. Keep the credential list limited to the people authorised to review the preview.

If the application fails, inspect conflicts with existing rewrite rules and the exact protected directory. Restore the saved configuration or disable only this directory’s protection while correcting the issue. Browser-cached credentials can make tests misleading.

Suppose a design team needs to review files in a private preview folder. First confirm that the protected directory is the one served by the preview URL. Protecting a similarly named folder outside that document root will not secure the page visitors actually open.

1. Save the current access configuration and identify anyone who legitimately needs the preview.
2. Create a dedicated preview credential through the supported directory-protection interface. Do not reuse the main hosting password.
3. Open the preview in a signed-out browser window. You should be challenged before the protected content is delivered.
4. Test a public page outside that directory to confirm the restriction has not spread further than intended.

Share the credential using an approved private channel and remove it when the review ends. If multiple reviewers need accountable access, consider whether your application supports individual user accounts instead of one shared directory password.

Why does the password prompt appear repeatedly?

Check whether the page loads assets from another protected path with different credentials. Also confirm the browser is requesting the expected HTTPS hostname. Send us the path and observed behaviour rather than the directory password when asking for assistance.

No. Access protection limits visitors, but application jobs, payment integrations and outgoing mail still require a separate safe staging configuration.

• Using SiteWorx advanced .htaccess controls carefully
• Redirecting a SiteWorx website to HTTPS after certificate setup
• Delegating SiteWorx access to a secondary user
• Deactivating a SiteWorx user while preserving the account

• InterWorx: Hspasswd And .htaccess