The browser receives a JavaScript verification page (aes.js / __test cookie challenge) instead of the application’s JSON response. This causes the widget requests to fail; the presence endpoint returns HTTP 403, and the widget endpoint sometimes responds with HTML and HTTP 200.
Could you please confirm whether this verification challenge can be disabled or exempted for these same-origin API routes, or advise how authenticated fetch/XHR requests should be supported on my hosting account?
Other Information
I understand if the challenge is a platform-wide security requirement. I’m not asking to bypass it from application code—only whether there is a supported hosting-side configuration or alternative.
Beep boop, I’m a bot! I dug through the forum to get you started. I sometimes get things wrong though, so do with this what you will until a human has a look.
The challenge can’t be disabled or exempted for particular routes. This article says the check covers every URL on your site and is mandatory on free hosting:
The same article says that same-domain AJAX/fetch calls made from a real browser work normally, so your widget requests shouldn’t normally hit the challenge. Something about those requests must differ from a normal in-page call.
Can you check, in your browser’s developer tools (Network tab), whether the failing requests go to exactly the same hostname as the page (djprshsportal.wuaze.com, with no www. or other variation) and carry the __test cookie in their request headers? Also, are these requests made by the page’s JavaScript in the browser, or by something else, such as a service worker, a separate app or a server-side script? The article says only requests from a browser that runs the page’s JavaScript and keeps its cookies get through.
XHR/fetch requests with the same website should just work.
The browser security system (which the bot already links to) works by check if a request contains a valid security cookie, and presents a Javascript challenge if it doesn’t. As long as you’re on the same origin, a valid security cookie should be passed along which allows the request to pass the security challenge.
But it seems that something is not working quite right there, and we’ll need to do some troubleshooting to figure out what that is.
The first thing we should check is if the requests from the messaging widget actually contain the security cookie. We can do that like so:
Open the Developer Tools in your browser (press F12 or find by clicking the triple dots in the top right corner of your browser → More tools → Developer tools).
Go to the Network tab.
Select the Fetch/XHR and Doc filters.
Refresh the current page.
Find the request in the list, click to open it, and check the Cookies tab. Verify that a cookie with the name __test is present there, and make note of it’s value.
Make an action that triggers a call to the messaging widget endpoints.
Find the request that doesn’t work in the list. Open it, go to the Cookies tab. Check if the __test cookie is included here, and that the value matches what you noted before.