Auth Request to local URL causing timeout issue.

[jonnywilliamson]

This might also be related to #8

My setup in server.js during development is to use a .dev url on Homestead.

I was having no issues using normal channels and then I started to play with private channels. I was having very strange results where I could only listen to a broadcasted event in my private channel about 30% of the time.

So I knew it was working, and that it was authorising ok, only about 70% of the time I was testing I couldn't receive the event....

After a lot of debugging I finally found out that the serverRequest sent by laravel-echo-server to my authHost url was taking exactly 2mins to get a response.

I added some console.log here and this is what I got when I ran the server:

 ✘ vagrant@homestead  ~/Code/new.nn.com  node server.js development

EchoServer: "Server running at http://new.wn.dev:6001"
authentication {"url":"http://new.wn.dev/broadcasting/auth","form":{"channel_name":"private-App.User.1"},"headers":{"X-CSRF-TOKEN":"ktHclK1jxdnerkkV49df1r0LyydcOuHHjcoxXafH"},"rejectUnauthorized":false}

About to send Request at 1472463808
Response received at 1472463928

Because I wasn't always waiting the full 2 mins before firing an event, it appeared to me that the channel wasn't working when in fact I just hadn't authorised yet. If I waited the 2 mins then fired my events, I got them every single time.

2 mins seemed like a very precise time, so i did some more testing.

If I changed it to a normal URL (say google.com), the request was sent instantly and I got a response (albeit an incorrect one), but as soon as I tried setting it back to my development URL it took exactly 2 mins again.

That makes me believe that there's some issue with the dnslookup for sending requests. It seems like it was trying to lookup my .dev URL on the internet, and not use my local dns /etc/hosts to route directly back to the same server. It appears that it's set for a timeout of 120 secs before it gives up on looking online and reverts back.

Again I know very little about Node.js, but from what i can gather, it seems like you are using the Request library, and when I went looking in there it seems like the Request library using the core Node.js library to deal with dns lookups etc.

SO. Do you have any idea how to fix this? Is there something in your library we can add as a request option? Is the a bug in the Request library, is it a Node.js issue? That's as far as I could debug too and now I need some help if you are able!?

Thank you.

[tlaverdure]

@jonnywilliamson Does this help?

#14

[jonnywilliamson]

No. This is still plaguing me and I cannot find a reason.

I can get receive ALL broadcasts sent to the page, as long as I open the page and wait exactly 2 mins for something to timeout. It's crazy, I don't even know where to debug.

I ran a test. I open my webpage and have 3 listeners set up.
1 for public broadcast (no auth needed)
1 for private broadcast (auth needed)
1 for presence channel (auth needed).

I can see that as soon as I open my page, an ajax/socket.io request is instantly sent to my authHost (http://new.wn.dev) with all the correct data. However it never gets to the laravel app....it seems to timeout exactly 2 mins later.

In another window I fire off 3 events, 1 public, 1 private and 1 presence channel. The public one gets received (console log) instantly. The other 2 never arrive.

As soon as 2 mins is up and I reload page 2 to send the 3 events, all 3 get logged immediately!

Any thoughts gladly received!

[jonnywilliamson]

I've never spent so much time on a bug before - coming up on 3 weeks now. But I finally have an answer to this.

And of course it's incredibly simple and complex all at the same time.

After hours and hours of testing code and debugging variables, I finally noticed that one of my sites was resolving to 127.0.53.53 and not 127.0.0.1 as would be the norm on vagrant.

This stood out like a sore thumb and I went googling.

I finally came across a few threads and it all came together.

My websites all use .dev as the domain TLD and I've been using that for quite a while without ever having an issue before. However, it appears google is in the process of being the owner of the .dev domain and in doing so a name collision occurs when you try and use it for your own projects in certain circumstances and software versions.

Here's more info : https://www.icann.org/resources/pages/name-collision-2013-12-06-en#127.0.53.53

So what was happening was that node was trying to resolve my domain of new.wn.dev and was being directed to 127.0.53.53 instead of 127.0.0.1

For whatever reason with software versions installed and Ubuntu versions etc, this then caused a timeout for exactly 120 secs before everything started to work. (May also be related to this http://www.sekuda.com/overriding_the_default_linux_kernel_20_second_tcp_socket_connect_timeout)

The Fix

So simple. Stop using ANY TLD that is in the process of being setup/bought (eg .dev) and use one that has been designed specifically not to be used in the future. eg .test

More suggestions here: https://iyware.com/dont-use-dev-for-development/

As soon as I changed my developement domains to .test everything just clicked into place.

Public, private and presence channels all work now instantly without any timeouts etc.

And finally I can sleep without having this at the back of my mind!

For the record, here's what my laravel-echo-server.json file looks like.

{
    "appKey": "k7mo168sssssssssssssssssssssss6qtfh",
    "authEndpoint": "/broadcasting/auth",
    "authHost": "http://new.wn.test",
    "database": "redis",
    "databaseConfig": {
        "redis": {},
        "sqlite": {
            "databasePath": "/database/laravel-echo-server.sqlite"
        }
    },
    "devMode": false,
    "host": "localhost",
    "port": "6001",
    "protocol": "http",
    "referrers": [],
    "sslCertPath": "",
    "sslKeyPath": "",
    "verifyAuthPath": true,
    "verifyAuthServer": false
}

I hope this helps someone.