The Knowledge article “Flow Execution Failure With a “Server error processing request” Error” provides very little in the way of clarification or guidance on how to get more detailed information about the failure state. There doesn’t seem to be a way to actually obtain the response details of an failed external HTTP call. It doesn’t get logged in Action logs, like console.log statements in Actions.
I’m observing this error state when using the HTTP Request Integration in a Flow. It doesn’t seem possible to get any additional context regarding the details of the failed request, when it fails.
I’ve been able to determine that it has something to do with the domain I’m trying to call being proxied by Cloudflare, because when I disable the proxy, it all works. However I’m pretty sure (I might be wrong though, memory is a weird thing) that this worked before, with the proxy.
What I was able to observe, in my debugging attempts, was that if I make the same request inside an Action using Axios, Cloudflare blocks the request with their “Bot fight mode”, as shown in their event log. However in the HTTP Request Integration, when it fails, no such event shows up in Cloudflare logs, which would seem to indicate it’s not the “Bot fight mode” at play.
I would be extremely helpful to get detailed insight into what it is actually happening and why.
I am sorry about the issues that you are having with the HTTP Request component inside the Auth0 Flows. Due to the fact that it is a closed, managed component, you are unable to access any request/response data. The flow will simply fail whenever it does not receive a non 200 HTTP response and this is a design choice in order to keep the flow builder clean and simple.
From what I understand, the issues seem to be on Cloudflares side whenever the proxy is being enabled. Some of the possible causes that I am able to think of at this time would be:
Managed Rules: Cloudflare’s WAF has a set of managed rules that can block requests from certain IP addresses, user agents, or based on the content of the request itself.
Custom Rules: You may have a custom WAF rule that is silently blocking the request.
Rate Limiting: A rate-limiting rule could be blocking the request if it’s considered to be coming too quickly.
IP Reputation: The IP address range used by Auth0’s Actions could have a low reputation score, triggering a block. The HTTP Request Integration might use a different set of IP addresses than the ones used by Actions, explaining why you don’t see the same log entry.
Otherwise, my other suggestion would be to make the specific HTTP call using a custom action instead of using the HTTP Integration component if possible. You would need to create a new Action and use a dependency like axios or node-fetch to make the HTTP request. Inside the action Action, you could try using a try...catch block to make the request. This way, you should be able to log the contents of the error, including the response status and body, helping you diagnose the issue. The action code using axios would look something like this:
exports.onExecutePostLogin = async (event, api) => {
const axios = require('axios');
try {
const response = await axios.get('https://your-cloudflare-proxied-domain.com/api/endpoint');
console.log('Success:', response.data);
// Continue your logic with the successful response
} catch (error) {
if (error.response) {
// The request was made and the server responded with a status code
// that falls out of the range of 2xx
console.log('Error Status:', error.response.status);
console.log('Error Data:', error.response.data);
console.log('Error Headers:', error.response.headers);
} else if (error.request) {
// The request was made but no response was received
console.log('No Response Received:', error.request);
} else {
// Something happened in setting up the request that triggered an Error
console.log('Axios Error:', error.message);
}
// You can also stop the flow with a custom error message
// api.access.deny('Request to external service failed.');
}
};
If I can help with anything else regarding the matter, let me know!
Thank you for getting back to me and the detailed reply.
I have a single custom rule that allows ips from Ireland and Germany, which I understand are the relevant countries for the EU region. I also tried allowing all the auth0 ips from the EU region. I also tried simply disabling the custom rule. With no effect. The only thing that seems to have a visible effect is indeed, disabling the proxy.
Regarding making a HTTP call using a custom action, please note that I did do that, as mentioned in my comment
What I was able to observe, in my debugging attempts, was that if I make the same request inside an Action using Axios, Cloudflare blocks the request with their “Bot fight mode”, as shown in their event log. However in the HTTP Request Integration, when it fails, no such event shows up in Cloudflare logs, which would seem to indicate it’s not the “Bot fight mode” at play.
It would be interesting to understand, from your side, given that you would have access to the internals, why the same request would behave differently from a custom action and from the HTTP Request. Your suggestion to try the same request in a custom action, would seem to indicate that at least you have an expectation that the requests would be “equivalent”, but alas, they seem not to be.
The team responsible for the Auth0 Flows and the HTTP Request surely will have access to more detailed information via their internal logging, that might shed light into the ultimate cause of the failure and the discrepancy in behavior between a request via the HTTP component and a request via a custom action.
