Best practise for multiple apllications

[kpilard]

Hello, we want to use this library in multiple applications. We are using the Pusher subscriber to send our messages to the echo server. This works great. My questions are:

How can we access the channels for an specific app_id? Can we set an authEndpint for each client?

Is there a best practise to handle multiple applications (host one echo server per apllication for example)

[barryvdh]

Laravel-echo-server uses 1 application. Namespaces is not (yet) implemented.

[kpilard]

Is there a preferred API? I would try to implement it

[barryvdh]

Not sure, namespaces are part of the SocketIO server; https://github.com/socketio/socket.io/blob/master/docs/API.md#namespace

But this would also need seperation at the API level, which is possible with the Http API, but not with redis so easily I think.

[kpilard]

i think you have three options: prefix the Redis key, map a redis databse to an app_id or map a redis instance to an app_id.

What is the current use case for multiple clients? Is it only the api access? Is an client (appi_id) equal a names or can a client access multiple namespaces?

[barryvdh]

The current use case is only multiple api clients, but same channels/connections etc. (To map pusher api). For multiple apps, current approach would be running multiple socketIO instances on different ports/configs.

[krembo]

I did this for staging and production on the same server. Used different default queue per environment and prefixed each broadcast channel with environment name. Also used two different echo-servers on two different ports, however I think it's not a must, because users subscribed to different channels and both server get all broadcasted channels anyway.

[rafwell]

Same here. I'm running test and production environment at same webservicer, in diferent subdomains. I've tried run 2 instances of laravel-echo-server on port 6001 and 6002, but the events are firing for both.

[catalinux]

@rafwell : do you use the same redis server?

[rafwell]

@catalinux yes, same server.

[barryvdh]

Make sure you use a different redis database for each instance.

[barryvdh]

To be clear, you should probably change the Redis database on your Laravel broadcasting app. Both your echo-servers are listening to the same broadcasting database.

[rafwell]

I think you are right. I've stopped my websocket of test env and continue receiving messages at production. you can help me how configure different database for environments? Whiches files i need change?

[rafwell]

In my laravel app ive modified the file config/database:

'redis' => [

        'cluster' => false,

        'default' => [
            'host' => env('REDIS_HOST', '127.0.0.1'),
            'password' => env('REDIS_PASSWORD', ''),
            'port' => env('REDIS_PORT', 6379),
            'database' => env('REDIS_DB_NUM', 0),
        ],

    ],

in my .env ive set a REDIS_DB_NUM for production and other for test env. But the problem persist. Also, can I use letters like redis database name or just numbers?

[ghost]

Hey guys, I don't think Redis broadcasts to individual databases, as per their docs. I was curious about this as well, as I just started developing a Laravel app with Laravel-Echo-Server. I currently have my dev and prod environments on the same server.

https://redis.io/topics/pubsub

Database & Scoping Pub/Sub has no relation to the key space. It was made to not interfere with it on any level, including database numbers. Publishing on db 10, will be heard by a subscriber on db 1. If you need scoping of some kind, prefix the channels with the name of the environment (test, staging, production, ...).

I think my approach will be to prefix channels using env(environment) in the event's broadcastOn() method. If you guys have both environments working, try that and let me know if that works out. Note, you will need to pass the environment down to your clients when instantiating a WS connection via Laravel Echo, too.

[rafwell]

@cdr95985 i think this will work, but is poor security solution, a bad guy will can hear events of another's environment. Think in a shared host with many applications.

I will change my code soon and send the result here.

[ghost]

@rafwell You're right, it doesn't seem like a very good security practice, however, I think that if we use private channels and channel authentication (channels.php) really well, then you might be okay... From face-value, I think the only way a bad guy could get into another environment channel is if their user (or the user they are impersonating) has rights to that channel.

Perhaps you could lock down channels on an environment-level as well, ie) disallow anyone but users with X roles can access Y,Z,A environments. You could wrap all of the channels.php in their own validation system in that regard.

I'm just rambling though. Idk how we could make it more secure.

[catalinux]

@rafwell : cand give us detalis who is this bad guy?

An user that has acces to your redis server?

[rafwell]

@cdr95985 after change my code to use channels test.chat.{userID} and prod.chat.{userId} the problem of hear events from another environment has solved. About the security, i will change my code to use private channels.

@catalinux someone who has a link:port can hear messages from all users on channels (chat.1, chate.2, etc. the number is the id of my user), but now my channel is public, i need change that to private to see if is possible hear events from other domain who use the same redis server.

[Insua]

Here is my solution,I use defined prefix to solve it. 1st,in dot env file

MIX_BROADCAST_PREFIX=

2nd,echo.js

let prefix = process.env.MIX_BROADCAST_PREFIX || ''
window.Echo.private(`${prefix}channel-private`)

3rd,channels.php

Broadcast::channel(config('site.echo_server_prefix').'channel-private',function($user){
 ......
});

finnaly,in Job file

return new PrivateChannel(config('site.echo_server_prefix').'channel-private');

every thing is ok