Auth0 Home Blog Docs

Cannot send request to exposed local API via rule

api
rules
localhost
request

#1

I’ve got a simple test API I’ve built on my localhost (exposed by IP).

Inside a rule, I have the following code:

var request = require('request@2.27.0');

request({
        method:'PUT',
        url: 'xxx.xxx.x.xxx:3000/api/signup',
        json: userData
    }, function(err, response, body) {
        console.log(err);
        console.log(response);
        console.log(body);
        if (err) return callback(err);
        user.app_metadata.service_user_id = body.service_user_id;
    });

I’ve placed console logs before and after the callout and they are printed, but the logs are not printed from the response function… as if the request never happened.

I have tried changing the IP to a web domain responding with JSON data - works.
I’ve also tried this exact same code locally and it works as expected.

When this rule runs, I see no incoming traffic to my local server - so it definitely isn’t requesting anything.

Is there any reason why Auth0 would refuse to execute the request?


#2

It would depend on the actual IP address you are using; if it’s a private IP address, for example something on the range 192.168.0.0 to 192.168.255.255 then it would be normal for your machine to not receive any call. This range is meant for private network usage so only other machines within that same local private network would be able to reach IP addresses in that range.

This would also explain why the IP associated with a web accessible domain that just returns JSON would work. The rules engine will only be able to call systems that can be addressable over the Internet (assuming that any firewalls in place would also allow that call).

In terms of the reason for not seeing any output immediately, assuming it’s a private IP address then it can’t be that unexpected. The request can be trying to target a machine that will simply ignore you. If you include a short timeout configuration you’ll likely get a timeout error and console output.


#3

You are correct. I think where my confusion lay was that I was thought it was a publicly exposed IP address as I was able to access it from services such as Browserstack but I have since found that Browserstack has access to the local network.

Thanks for your clarification.


#4

Just to ensure a workaround is stated:

I’ve set up and used localtunnel.me to do my testing and it has worked successfully. I then just point the URL of the request to the localtunnel.me URL and it loads up my local server.

Brilliant!


#5

Just to ensure a workaround is stated:

I’ve set up and used localtunnel.me to do my testing and it has worked successfully. I then just point the URL of the request to the localtunnel.me URL and it loads up my local server.

Brilliant!


#6

No worries, for increased visibility and the benefit of others I moved your comment with a workaround to an answer; thanks for sharing.


#7