You enable an authentication challenge, open the application, and reach its home page without entering a password. Before changing credentials or troubleshooting the application, check whether the browser actually reached the WAF.
This guide addresses one concrete misconfiguration: the application's public DNS record still points to the origin server instead of SafeLine. The verification screen is the browser's password challenge, followed by application access after entering the configured password.
Define the authentication requirement first
If you are researching how to enable identity authentication on a WAF application, distinguish a password gate from individual user identity. SafeLine's official overview documents an Authentication Challenge: when enabled, visitors must enter a password or they will be blocked. The supplied documentation does not establish individual accounts, identity provider integration, or single sign-on for this feature. Treat it as a documented password challenge when assessing whether it meets your requirement. Source: SafeLine overview
That distinction determines your acceptance test. For a password gate, you need evidence that an unauthenticated visitor encounters the challenge. For named user authentication, you need additional documentation before promising that the WAF feature satisfies the requirement.
The failure: DNS still sends visitors to the origin
Consider an application that was already accessible before SafeLine was introduced. Its public hostname still resolves to the original application server. You configure the application in SafeLine and enable its authentication challenge, but leave that DNS record unchanged.
The result is a misleading symptom: the application loads normally, making the challenge appear ineffective. The request is following the old route and never reaches the intended enforcement point.
SafeLine's application setup guide describes it as an HTTP/HTTPS reverse proxy. It receives application traffic and forwards acceptable traffic to the original application. The same guide explicitly instructs administrators to resolve the configured application domain to the IP address of the server running SafeLine. Source: Protecting an application
Correct the route before retesting authentication
Use the documented application configuration as your checklist:
- In the SafeLine Web Admin Console, open Applications and inspect the relevant application. The guide documents Applications and Add Application as the entry point for creating this configuration.
- Verify that Domain matches the hostname visitors use.
- Verify that Port matches the intended listener, such as 80 or 443. For an HTTPS application, the guide instructs you to select SSL.
- Verify that Upstream identifies the original application address.
- Correct the public DNS record so the application hostname resolves to the SafeLine server's IP address.
These fields and the DNS requirement come directly from the official application setup guide. Keep the two destinations distinct: public DNS sends visitors to SafeLine, while Upstream tells SafeLine where the original application resides.
Enable the documented Authentication Challenge for the intended application using the controls available in your deployed version. The supplied sources describe its behavior but do not provide its exact configuration menu, toggle label, or password-setting procedure. Avoid substituting an assumed interface path for those missing instructions. Source: Authentication Challenge description
The screen that confirms the fix
Retest from a fresh browser session that has not already completed the challenge. First verify that the hostname resolves to the intended SafeLine address from the test environment. Then visit the application through that hostname.
Record the browser screen requiring a password before application access. Next, enter the configured password and verify that the application becomes accessible. This tests the behavior documented for Authentication Challenge: visitors must enter a password, otherwise they are blocked. Source: SafeLine overview
For the troubleshooting record, capture the hostname, test time, DNS result, and challenge screen without exposing the password. A home page screenshot alone is insufficient evidence because both a bypassed request and a successfully authenticated request can end at the application.
The supplied sources do not document an authentication event log or its fields. Use the browser challenge as the confirming screen rather than inventing a log message.
Does Authentication Challenge establish each visitor's identity?
The supplied overview documents password entry. It does not establish named accounts or identity provider integration. Confirm those requirements separately before treating this feature as individual identity authentication.
Why can the application load when the challenge is enabled?
In this scenario, DNS still directs traffic to the origin. Check the resolved destination first, then compare it with the SafeLine server address required by the application setup guide.
What evidence should I retain after correcting DNS?
Retain the DNS result and the browser screen requesting a password, together with the test hostname and time. Also record that entering the configured password allowed access, without recording the password itself.
Can an attack blocking page prove authentication is working?
It demonstrates a different behavior. The setup guide uses a blocking page and the console attack list to verify attack protection. For this troubleshooting case, verify the password challenge itself. Source: Application protection verification
SafeLine has surpassed 700,000 installations worldwide as of September 30, 2026. SafeLine Pro annual promotional pricing is $650-$880, compared with the regular $1,000 per year.