Broadcast Auth on Laravel Homestead about laravel-echo-server

[jonnywilliamson]

@pfeiferchristopher

I don't claim to be an expert here, but I don't think you are correct!

There are no auth headers needed to be sent to laravel when you are subscribing to a public channel.

To prove this, I've just set up a demo.

Here's my event:

<?php

namespace App\Events;

use Illuminate\Broadcasting\Channel;
use Illuminate\Queue\SerializesModels;
use Illuminate\Broadcasting\InteractsWithSockets;
use Illuminate\Contracts\Broadcasting\ShouldBroadcast;

class myPublicEvent implements ShouldBroadcast
{
    use InteractsWithSockets, SerializesModels;
    /**
     * @var
     */
    public $data;

    /**
     * Create a new event instance.
     *
     * @return void
     */
    public function __construct($data)
    {
        $this->data = $data;
    }

    /**
     * Get the channels the event should broadcast on.
     *
     * @return Channel|array
     */
    public function broadcastOn()
    {
        return new Channel('myPublicChannel');
    }
}

Here's my javascript to detect this event in my app.js file:

const app = new Vue({
    el: 'body',

    ready() {
        this.listen();
    },
    methods: {
        listen() {
            echo.channel('myPublicChannel')
                .listen('myPublicEvent', (event) => {
                    console.log('This is a public channel '+event.data);
                });
        }
    }
});

And I fire the event using a simple route in my web.php file

Route::get('/test2', function () {
    broadcast(new \App\Events\myPublicEvent('Here is the public data payload'));
    return 'done';
});

This is what happens when I load the webpage in one tab, and fire the event (via url /test2 from another).

And here's the console:

As you can see, no auth requests need to be sent to laravel. Yet my payload arrives.

[jonnywilliamson]

Finally! I think I've found someone with the same issue as me (#11)

Would you try this:

Make sure your echo server is running.

• Open your main webpage (the one that makes the websocket connection to the laravel echo server).
• Start your stop watch.
• Fire a PUBLIC event in another webpage and ensure you get the data come through ok. (You say you are getting these already so that means your setup is working)
• You can try a private event here, but it is unlikely to work as you are having problems.
• Wait exactly 2 mins before doing anything (and I mean 2mins, not "a few secs")
• Now try a private event again.... in my case they all work perfectly...AFTER the 2 min wait.

If your problem is anything like mine, for some reason when your echo server tries to make a request to the fake URL of http://gamejerks.app to authorise, something goes wrong when it tries to resolve the dns to that address.

It has to wait exactly 2 mins before it times out. Subsequent requests then work perfectly! It's a crazy bug. But one that I have been able to reproduce here on two different machines....both running vargrant/homestead on windows.

I'd be interested to hear if you have the same issue.

[jonnywilliamson]

Here's some more debug info using the websockets tab in googles chrome browser.

Just so the flow of events is understood, this is what I did.

1. Opened my webpage that should processes broadcast events.
2. Echo server attempts to send an auth request to my laravel server. You can see the data it attempts to send.
3. In a second webpage, fired 3 events that should be sent to the 1st page. One public event, and 2 private events (presence channel and private channel)
4. Only the public one makes it to the webpage 1.
5. After 2 minutes a presence event is detected on webpage 1, this could only happen if my authentication was working correctly.
6. I fire all 3 events again from webpage 2 and this time ALL arrive instantly.

[feenx]

Wow just research into this issue. I will try it when I get home, I'm away from keyboard right now. I'll update this response when I do.

[feenx]

Just tried to replicate what you were talking about and I didn't get a single private event even after 2 minutes. Here are my frames:

And here's the server running:

I absolutely love how fast the public events are using this method vs 3rd party api calls to pusher.io so I would love to see this work but I have no idea how it's coded haha.

[s3rg3]

Hello,

in laravel-echo-server/src/channels/private-channel.ts, on line 63 you have :

Log.error(error);

if you change this to:

Log.error(JSON.stringify(body));

you can have the request body of your error, which will help you to see what the error is about.

[jonnywilliamson]

@pfeiferchristopher

Thanks for posting your image. Unless I am misreading your picture you DO seem to be receiving private events!

Take a look at the edge and I have numbered some lines with red and blue numbers.

RED 1 & 2 show your webpage making an outbound connection to the echo server with the auth headers and the channel name to authorise.

BLUE 1 & 2 show INBOUND data from your webserver TO your webpage with data like user_id and parent_id.

Isn't that exactly what you were wanting?

The only strange thing is that it took between 20 and 45 secs for the data to be returned from your webserver, and that the event for the second auth request came before the first one.

As far as I can see, the system is working for you.

[feenx]

Not exactly.

The red numbers are public channel subscriptions. Then there's another private channel subscription as well.

All seen events are on public channels. If it was functioning correctly there would be a presence channel response.

And the reason for the seemingly long delay is the inbound responses aren't triggered by the outbound ones.

[feenx]

@s3rg3 I tried to do what you said but nothing in the output changed. I re-ran the laravel-echo-server start command after making changes and everything.

[feenx]

@s3rg3 upon further inspection it seems as though I wasn't editing the files I was actually using because I had it installed locally and globally.

So now I've removed laravel-echo-server from both and when I started to re-install it exclusively globally as the instructions suggest. When I realized there weren't any *.ts files at all. Or a /src/ folder so I seem to be mistaken somehow.

[feenx]

Perhaps I'm using an old version of Laravel Echo then because I'm definitely subscribing to the channels I said were public using Echo.channel() as you can see here:

        Echo.channel(that.model.type_slug + '.' + that.model.id + '.likes')
                .listen('Users\\LikeCreated', function(event)
                {
                    that.model.likes.push(event.like);
                })
                .listen('Users\\LikeDeleted', function(event)
                {
                    var like = _.find(that.model.likes, function(like)
                    {
                        return like.id == event.likeId;
                    });

                    that.$nextTick(function()
                    {
                        that.model.likes.$remove(like);
                    });
                });

Please excuse the non-ES2016 haha

[jonnywilliamson]

OK, I've looked into it more and it seems you are correct.

In my setup, a SEPARATE post request is made (even for a public channel). and it wasn't showing up in the Websocket Frames tab,

You can see the public channel registration payload here at the bottom of this image.

Sorry about that.

[feenx]

Indeed

[s3rg3]

@pfeiferchristopher i was referring to the file on github, on your local installation you should have a private-channel.js file.

Change the line log_1.Log.error(error); to log_1.Log.error(JSON.stringify(body));

[feenx]

@s3rg3 thanks I'll report back.

[jonnywilliamson]

Just found the source of my "bug" with connecting and getting a 2 min timeout. I left info here

#11 (comment)

Currently have all private and public events working.

@pfeiferchristopher You should also publish your BroadcastServiceProvider.php file incase there's an issue there.

[jimtendo]

Alright, I've been stuck with this for hours and have finally found out what the problem is.

Turns out I'm a massive idiot...

YOU MUST BE LOGGED IN TO USE PRIVATE CHANNELS.

@pfeiferchristopher Might be worth checking this. Make sure you are Auth'd.

[feenx]

So I think I may have found the issue. So once I managed to find the actual private-channel.js that the package was using I managed to throw some error logging around and eventually I just dumped the body of the response from `/broadcasting/auth'

I should say that at first I was getting 403 because my app redirects non-www to www but I set the authHost with www and fixed that.

What I found was a HttpException being thrown by RedisBroadcaster:49 which to my amazement throws said exception when no user is logged in. I was however most definitely logged in.

From what I can guess laravel-echo-server is not sending along the laravel_session cookie which makes the independent server requests to /broadcasting/auth done by a guest which can not be authorized to a private channel.

So any help would be appreciated, I'm not sure what needs to sent along to authenticate the currently logged in user or what not.

[feenx]

@jimtendo perhaps this is what you meant but in my browser I was logged in for sure even tried logging out and back in. But my guess is that the request being made from this package to /broadcasting/auth doesn't have any credentials or nothing to tell Laravel what user is logged in, etc.

[jimtendo]

@pfeiferchristopher Yeah, that was the same spot in the code where mine
tripped up.

If you're Auth'd on client'side, unsure why that errors tripping.

Dont think it would be related (especially considering public channels are
working for you) but do you have the csrf token as a tag?

Actually... maybe it's that your session driver is "file" (mine's set to
Redis) and your laravel-echo-server cannot access the session as a file?

Sorry, on phone atm. Hope that might help a little anyway.

On 16/10/2016 8:50 PM, "Christopher Pfeifer" [email protected]
wrote:

@jimtendo https://github.com/jimtendo perhaps this is what you meant
but in my browser I was logged in for sure even tried logging out and back
in. But my guess is that the request being made from this package to
/broadcasting/auth doesn't have any credentials or nothing to tell
Laravel what user is logged in, etc.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#53 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACsN3Uwfv85o_QApsKMPz-I5JIeXZVg_ks5q0fNrgaJpZM4KQ2zm
.

[feenx]

So I changed my dev session driver to redis as well and still no luck. What I did to try and figure this out was I started dumping things into the Log by editing RedisBroadcaster:49 by dumping $request->get(); I found only the channel_name and then I dumped session()->all(); and found only CSRF _token field.

So now I'm thinking about this. The authorize process doesn't make any sense to me. Laravel Echo (in browser) pings through a websocket to => Laravel-Echo-Server (running on node.js) which then fires a POST request back to my app => Laravel (which is a fresh request in, meaning no user is logged in).

But here's my question, how exactly is node.js (sending a POST request to laravel) supposed to know anything about my client (in browser) session at all. If it did work I feel like that'd be a wrong because then any 3rd party request to my app could be logged into random users because the CSRF alone doesn't not authenticate it simple makes sure the request was originated recently from my app itself.

[feenx]

Just in an attempt to make sure this is well documented I tried all my dev code for this package's implementation on my staging server. Got the exact same results, down to the HttpException being thrown because the auth request is not logged in, even tho I am logged in.

[JGdijk]

I'm stuck on this one myself, public channels are working fine but the private channels are resulting in the null error.

@pfeiferchristopher @jimtendo are you using this in combination with laravel passport?

[feenx]

Yes

On Mon, Oct 17, 2016, 10:20 AM JeroenGrasdijk [email protected]
wrote:

I'm stuck on this one myself, public channels are working fine but the
private channels are resulting in the null error.

@pfeiferchristopher https://github.com/pfeiferchristopher @jimtendo
https://github.com/jimtendo are you using this in combination with
laravel passport?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#53 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AI086D-AqC4UONLSowhaD3q74BXZs3nTks5q05JVgaJpZM4KQ2zm
.

[jimtendo]

@christopherpfeiffer I'm not in front of PC atm, but will dump the request
object that i get at Line 49 a bit later today. Might help you debug and
work out what should get passed to that by echo-server.

On 18/10/2016 2:20 AM, "Christopher Pfeifer" [email protected]
wrote:

Just in an attempt to make sure this is well documented I tried all my dev
code for this package's implementation on my staging server. Got the exact
same results, down to the HttpException being thrown because the auth
request is not logged in, even tho I am logged in.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#53 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACsN3W8-gODrmID4joeCFhQSbWw32oX0ks5q05IogaJpZM4KQ2zm
.

[JGdijk]

I caught the error in my homestead server and got the following if I output with log_1.Log.error(JSON.stringify(body));.

Whoops, looks like something went wrong.
1/1 HttpException in Broadcaster.php line 53 :
in Broadcaster.php line 53
at Broadcaster->verifyUserCanAccessChannel(object(Request), 'test-channel') in RedisBroadcaster.php line 53
at RedisBroadcaster->auth(object(Request)) in BroadcastManager.php line 306
at BroadcastManager->__call('auth', array(object(Request))) in Facade.php line 237
at Facade::__callStatic('auth', array(object(Request))) in BroadcastController.php line 19
at BroadcastController->authenticate(object(Request))
at call_user_func_array(array(object(BroadcastController), 'authenticate'), array(object(Request))) in Controller.php line 55
at Controller->callAction('authenticate', array(object(Request))) in ControllerDispatcher.php line 44
at ControllerDispatcher->dispatch(object(Route), object(BroadcastController), 'authenticate') in Route.php line 189
at Route->runController() in Route.php line 144
at Route->run(object(Request)) in Router.php line 642
at Router->Illuminate\Routing{closure}(object(Request)) in Pipeline.php line 53
at Pipeline->Illuminate\Routing{closure}(object(Request)) in CreateFreshApiToken.php line 48
at CreateFreshApiToken->handle(object(Request), object(Closure)) in Pipeline.php line 137
at Pipeline->Illuminate\Pipeline{closure}(object(Request)) in Pipeline.php line 33
at Pipeline->Illuminate\Routing{closure}(object(Request)) in SubstituteBindings.php line 41
at SubstituteBindings->handle(object(Request), object(Closure)) in Pipeline.php line 137
at Pipeline->Illuminate\Pipeline{closure}(object(Request)) in Pipeline.php line 33
at Pipeline->Illuminate\Routing{closure}(object(Request)) in VerifyCsrfToken.php line 64
at VerifyCsrfToken->handle(object(Request), object(Closure)) in Pipeline.php line 137
at Pipeline->Illuminate\Pipeline{closure}(object(Request)) in Pipeline.php line 33
at Pipeline->Illuminate\Routing{closure}(object(Request)) in ShareErrorsFromSession.php line 49
at ShareErrorsFromSession->handle(object(Request), object(Closure)) in Pipeline.php line 137
at Pipeline->Illuminate\Pipeline{closure}(object(Request)) in Pipeline.php line 33
at Pipeline->Illuminate\Routing{closure}(object(Request)) in StartSession.php line 64
at StartSession->handle(object(Request), object(Closure)) in Pipeline.php line 137
at Pipeline->Illuminate\Pipeline{closure}(object(Request)) in Pipeline.php line 33
at Pipeline->Illuminate\Routing{closure}(object(Request)) in AddQueuedCookiesToResponse.php line 37
at AddQueuedCookiesToResponse->handle(object(Request), object(Closure)) in Pipeline.php line 137
at Pipeline->Illuminate\Pipeline{closure}(object(Request)) in Pipeline.php line 33
at Pipeline->Illuminate\Routing{closure}(object(Request)) in EncryptCookies.php line 59
at EncryptCookies->handle(object(Request), object(Closure)) in Pipeline.php line 137
at Pipeline->Illuminate\Pipeline{closure}(object(Request)) in Pipeline.php line 33
at Pipeline->Illuminate\Routing{closure}(object(Request)) in Pipeline.php line 104
at Pipeline->then(object(Closure)) in Router.php line 644
at Router->runRouteWithinStack(object(Route), object(Request)) in Router.php line 618
at Router->dispatchToRoute(object(Request)) in Router.php line 596
at Router->dispatch(object(Request)) in Kernel.php line 267
at Kernel->Illuminate\Foundation\Http{closure}(object(Request)) in Pipeline.php line 53
at Pipeline->Illuminate\Routing{closure}(object(Request)) in CheckForMaintenanceMode.php line 46
at CheckForMaintenanceMode->handle(object(Request), object(Closure)) in Pipeline.php line 137
at Pipeline->Illuminate\Pipeline{closure}(object(Request)) in Pipeline.php line 33
at Pipeline->Illuminate\Routing{closure}(object(Request)) in Pipeline.php line 104
at Pipeline->then(object(Closure)) in Kernel.php line 149
at Kernel->sendRequestThroughRouter(object(Request)) in Kernel.php line 116
at Kernel->handle(object(Request)) in index.php line 53

[JGdijk]

I changed

Broadcast::channel('test-channel', function ($user, $userId) { 
            return true;
        });

to

Broadcast::channel('test-channel', function ($user) { 
            return true;
        });

and it seems to be working for now, not sure how those params are being set but i blindly copied-pasted it from the default one when i made it. after removing the second paramater ($userId) it started working.

edit 1
also, in your broadcastserviceprovider, don't prefix your channel-name with private-. that seems to give the same error

edit 2
in the laravel-documentation it is actualy described how the parameters are working

[feenx]

Here's an idea but I'm afk. I can't remember where the routes are defined for broadcasting but perhaps the web middleware group isn't being applied so neither is the session, or cookies middleware. That would keep anything from being authenticated without using passport.

[JGdijk]

With my previous awnser i got it running with laravel homestead and laravel passport. if you can't fix it send me the code of your event / service provider from laravel so i can compare it with mines.

[jimtendo]

How did you guys go about dumping the $request object in RedisBroadcaster::auth()?

At the start of the function I'm using:
\Log::info(json_encode($request));
... but this dumps
{"attributes":{},"request":{},"query":{},"server":{},"files":{},"cookies":{},"headers":{}}
... into the log (empty).

@pfeiferchristopher The routes are generally registered in the BroadcastServiceProvider::boot() method with:
Broadcast::routes();

I didn't have to add anything to the 'web' group in order to get mine running.

[feenx]

@jimtendo you're right it was in BroadcastServiceProvider::boot() as Broadcast::routes(); and it does add it to the web middleware group.

I was editing RedisBroadcaster @ line 49 (I think) where it throws a HttpException because $request->auth() fails. I just added var_dump($request); But this was on Laravel's end.

I managed to finally get the actual Whoops page by editing this package's private-channel.js and dumping the response into the log so I could figure it out. Originally it was getting a redirect that it didn't follow, now that it actually hits a HttpException it shows up in my logs too.

[jimtendo]

Unfortunately, I ran into an infinite recursive using print_f, so ran with \Log::info(var_export($request, true));

array ( 'USER' => 'vagrant', 'HOME' => '/home/vagrant', 'HTTP_CONNECTION' => 'close', 'HTTP_CONTENT_LENGTH' => '58', 'HTTP_CONTENT_TYPE' => 'application/x-www-form-urlencoded', 'HTTP_HOST' => 'dash.alzed.com.au.test', 'HTTP_X_REQUESTED_WITH' => 'XMLHttpRequest', 'HTTP_COOKIE' => 'io=9iRYtqIvKYQ8JpMNAAAO; XSRF-TOKEN=eyJpdiI6ImhGV0ZrNkFFTWlkTEZrdFJsVk5yTUE9PSIsInZhbHVlIjoidVNPbmxPMVwvMVwvUFRJQ0QxTGljeWoyY3pUVDlVakpGU21MeXBEZ2NONVhFVllkTW1aYkd6NmllVzF5NUFmRlVRSFM1RGZabU5ZWHNEUDEyTTY3RUlQZz09IiwibWFjIjoiYzhlZmU1Yzc1ZmUyYTI4M2Y0ZjZmNTU4ODUwMjAwMjU0NmEwZGJmMjNiMmM4NzIyY2QwNjdjN2M1OTdkYTExZiJ9; laravel_session=eyJpdiI6IjRQK0kyMHlmdk03c2tYOVBGdERWXC9RPT0iLCJ2YWx1ZSI6IkxodXB1ZjA1T1o2ZVo3ZDVxeE00MjRQT1wvTUZZZTN0bkY1a3ZCYUxLTlh3YUlqMVNvWHZKWFR6QXQyRVRRRlJNSTVKRXhXU3JaTVlKa1pSQVdyd21mUT09IiwibWFjIjoiNDllNDk1OWJlN2NiM2E4YTQ3YjMzMDJhYzc4NzBkN2I0MjdmNWM1YTYxNGRhYWFiYTU2NmY3ZDU4ZWYyNTc4MyJ9', 'HTTP_X_CSRF_TOKEN' => 'hPtv035BKsAvWiNxTQ1Wb9ySG05of5LL5FvCiW47', 'REDIRECT_STATUS' => '200', 'SERVER_NAME' => 'dash.alzed.com.au.test', 'SERVER_PORT' => '80', 'SERVER_ADDR' => '192.168.10.10', 'REMOTE_PORT' => '35376', 'REMOTE_ADDR' => '192.168.10.10', 'SERVER_SOFTWARE' => 'nginx/1.11.1', 'GATEWAY_INTERFACE' => 'CGI/1.1', 'SERVER_PROTOCOL' => 'HTTP/1.1', 'DOCUMENT_ROOT' => '/home/vagrant/Projects/AlzedDash/www/public', 'DOCUMENT_URI' => '/index.php', 'REQUEST_URI' => '/broadcasting/auth', 'SCRIPT_NAME' => '/index.php', 'SCRIPT_FILENAME' => '/home/vagrant/Projects/AlzedDash/www/public/index.php', 'CONTENT_LENGTH' => '58', 'CONTENT_TYPE' => 'application/x-www-form-urlencoded', 'REQUEST_METHOD' => 'POST', 'QUERY_STRING' => '', 'FCGI_ROLE' => 'RESPONDER', 'PHP_SELF' => '/index.php', 'REQUEST_TIME_FLOAT' => 1476836490.7826591, 'REQUEST_TIME' => 1476836490, ),
The above is an example of WORKING request received at RedisBroadcaster::auth().

Hope this helps somewhat.

[feenx]

@jimtendo so here's one more question for ya. If you open chrome developer tools, and go to Network and then load the site. Click on the websocket network row and under "Headers" you should see something like this:

What I'm curious is, if the laravel_session cookie is being sent through the websocket headers, where as you can see my definitely are not. But based on what you sent last, yours is being sent along which I believe would in fact authenticate that request to the current user in the browser.

[jimtendo]

@pfeiferchristopher Yep, that's there on mine.

Must be something on the client side for you? Let me know if you'd like samples of any of my other configs.

[feenx]

I figured it out. My app runs on www.gamejerks.app which is what laravel sets the cookie domain too. So my laravel auth cookies were on that domain, where as I was running the echo server on gamejerks.app so when the websocket connected it didn't have access to my auth cookies and didn't send them.

I can't believe this was the issue the entire time. So far I'm going good now. Got presence channels working so far, gotta fix joining/leaving though. After a bit of testing I'll come back and close this issue.

[mdixon18]

So is it possible to have the echo server on a different server/domain to the app?

[devdbrandy]

Faced the same issue, figured I had to enable BroadcastServiceProvider... Open config/app.php, and uncomment line App\Providers\BroadcastServiceProvider::class in providers array. Hope someone finds this helpful

[1mursaleen]

Soultion to Common Problems faced by many users while setting up Laravel Echo
https://gist.github.com/rauschmerscen/2f2265976d59267f3bfccb339b27be44

[mwleinad]

@jimtendo hello there, can you share samples of your configuration for laravel-echo-server.json and your client? please? I've been trying to send those cookies and no matter what I do doesn't seem to work
Also, what version are you using? I might be in a buggy version :(

Hmm, I just noticed this is from 2018 haha, and I'm using wss which makes me think I might need to use https as the protocol (I'm using http). Ugh no idea.

[jimtendo]

@jimtendo hello there, can you share samples of your configuration for laravel-echo-server.json and your client? please? I've been trying to send those cookies and no matter what I do doesn't seem to work Also, what version are you using? I might be in a buggy version :(

Hmm, I just noticed this is from 2018 haha, and I'm using wss which makes me think I might need to use https as the protocol (I'm using http). Ugh no idea.

Yeah, sorry mate, this is ancient (was surprised to see a notification for it!)

I haven't developed with Laravel for a few years, but it might be the HTTPS thing you called out above. Also - make sure you've got the exact same (major.minor.patch version inclusive) version of socket.io on both the server and client (though there should be compatibility between minors, I had a scenario recently where there they didn't communicate correctly).