It's just a brodcaster?
How the authorisation works here?
If there is 100 users , everyone will get everyones data??
I'm sorry I'm just a noob trying new things
Great questions! SSE isn't just a broadcaster—it's a way for the server to push updates to clients in real-time over a single HTTP connection.
As for authorization, it usually works by validating the user's identity before establishing the SSE connection, just like any other secure connection.
// Sends a GET request to /eventsconsteventSource=newEventSource('/events',{headers:{'Authorization':'Bearer your_token_here'}});// Or CookiesconsteventSource=newEventSource('/events',{withCredentials:true// Ensures cookies and credentials are sent with the request});
The server responds with an HTTP response that has a Content-Type: text/event-stream header and keeps the connection open to send multiple events over time.
Regarding your last question: If you have 100 users, each client will only receive the data that the server sends to it. Typically, you would send specific updates based on the user’s permissions or the data they’re subscribed to, so not everyone gets everyone else's data.
SSE is simplest described as a regular HTTP request with a streaming response; the streaming payload is events.
The server closing the response is unexpected, so the client sends another request to start again.
The client will close the connection when it is done with the request.
WS requests on the other hand convert (“upgrade”) the HTTP request to something outside of the HTTP spec to get access to the sockets that the original HTTP request was using.
In both cases the server has to manage a distinct connection to each user; however SSE connections tend to be less demanding on server resources and SSE may work where WS won't; like when firewalls block non-HTTP traffic. But both require an always-on server,so neither of them is suitable for a serverless environment.
@5p4r70n , you would have to use your existing auth model. For example, we use sse to send notifications to users of our system when they are in the admin console. The app uses tokens so the server only receives authenticated messages.
Also since we have info on the user via the token we store some identifier info on the cached connection pool so when a SSE is generated we can send only to clients that match the recipient id.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It's just a brodcaster?
How the authorisation works here?
If there is 100 users , everyone will get everyones data??
I'm sorry I'm just a noob trying new things
Great questions! SSE isn't just a broadcaster—it's a way for the server to push updates to clients in real-time over a single HTTP connection.
As for authorization, it usually works by validating the user's identity before establishing the SSE connection, just like any other secure connection.
Regarding your last question: If you have 100 users, each client will only receive the data that the server sends to it. Typically, you would send specific updates based on the user’s permissions or the data they’re subscribed to, so not everyone gets everyone else's data.
SSE is simplest described as a regular HTTP request with a streaming response; the streaming payload is events.
WS requests on the other hand convert (“upgrade”) the HTTP request to something outside of the HTTP spec to get access to the sockets that the original HTTP request was using.
In both cases the server has to manage a distinct connection to each user; however SSE connections tend to be less demanding on server resources and SSE may work where WS won't; like when firewalls block non-HTTP traffic. But both require an always-on server,so neither of them is suitable for a serverless environment.
Ok, go it
The server and client will keep this connection alive for future server-to-client event notifications.
Thanks! 😊
@5p4r70n , you would have to use your existing auth model. For example, we use sse to send notifications to users of our system when they are in the admin console. The app uses tokens so the server only receives authenticated messages.
Also since we have info on the user via the token we store some identifier info on the cached connection pool so when a SSE is generated we can send only to clients that match the recipient id.