We have a website deployed to an Azure App Service, and for the most part it's working fine. The exception is an ASHX handler we've written to provide some pre-signup validation in our Azure B2C authentication layer. This handler is expected to return both an HTTP status code indicating failure, and a JSON payload with the exact error conditions including a friendly error message for the user signing up. The handler is located in the site root directory, and the configuration (to the best of our current knowledge) matches another Azure App Services site that uses the same B2C auth provider, the same ASHX verification handler, and is working correctly.
There are several possible HTTP status codes that can be returned, including 401 (calling code didn't correctly authenticate - the handler uses basic auth with a random username/password over HTTPS, nothing fancy, just keeping your average script kiddie at bay), 400 (sign-up information doesn't match an expected "invited" user), 500 (something went wrong on our end), and if none of those happen, 200 (user is invited and expected, proceed).
When run locally in IIS Express, everything's hunky-dory, the handler produces the proper response payload and status code. However, once deployed into Azure App Services, the handler's error responses keep getting rewritten or redirected. 401s get tossed to our B2C provider (even though all authentication/authorization logic is initiated from application code, the server's configured for Anonymous access with no knowledge of our B2C provider), which if a user's already logged in creates an infinite redirect loop. 400s and 500s get very basic text responses of "Bad Request" or "Internal Server Error", while only a 200 "OK" includes the expected JSON payload.
We have tried:
- Using the
<customErrors mode="Off" />tag within a location section specifying the ASHX - No change in behavior - Using the
<customErrors mode="Off" />tag in the site's main system.web section - No change in behavior - using an httpErrors section (in location and globally) to specify
existingResponse="PassThrough"behavior - No change in behavior - using an httpErrors section (in location and globally) to explicitly clear any error redirects - No change in behavior
- Hardcoding a 200 response code, but specifying the actual status code in the payload (it's expected) - doesn't work, the status code of the response is paid more attention by B2C than the one in the payload, if it's 200 the validation is assumed to pass.
At this point, we're stumped; there's something in this Azure App Services deployment that is configured differently from our other, working site, and we can't see or think of where that could be. We must get this handler producing the desired JSON response regardless of the HTTP code specified.