Both the "connected" and the "_sockets" maps were used to track the
Socket instances in the namespace.
Let's merge them into "sockets". It's a breaking change, but:
- the "sockets" object did already exist in Socket.IO v2 (and appears in some examples/tutorials)
- "sockets" makes more sense than "connected" in my opinion
- there was already a breaking change regarding the "connected" property (from object to Map)
Breaking change: the "connected" map is renamed to "sockets"
After a given timeout, a client that did not join any namespace will be
closed in order to prevent malicious clients from using the server
resources.
The timeout defaults to 45 seconds, in order not to interfere with the
Engine.IO heartbeat mechanism (30 seconds).
The underlying Engine.IO server now supports a 'cors' option, which
will be forwarded to the cors module.
Breaking change: the 'origins' option is removed
Before:
```js
new Server(3000, {
origins: ["https://example.com"]
});
```
The 'origins' option was used in the allowRequest method, in order to
determine whether the request should pass or not. And the Engine.IO
server would implicitly add the necessary Access-Control-Allow-xxx
headers.
After:
```js
new Server(3000, {
cors: {
origin: "https://example.com",
methods: ["GET", "POST"],
allowedHeaders: ["content-type"]
}
});
```
The already existing 'allowRequest' option can be used for validation:
```js
new Server(3000, {
allowRequest: (req, callback) => {
callback(null, req.headers.referer.startsWith("https://example.com"));
}
});
```
In previous versions, the Socket#id attribute was equal (or derived,
for a non-default namespace) to the underlying Engine.IO id, which is
used as a mean to authenticate the user throughout the Engine.IO
session and thus is sensitive information that should be kept secret.
The problem with reusing the Engine.IO id is that users could be
tempted to transmit this id to other clients, in order to implement
private messaging for example.
So we'll now generate a new random id for each new socket.
Please note that this id will now be different from the one found in
the query parameters of the HTTP requests.
In previous versions, a client was always connected to the default
namespace, even if it requested access to another namespace.
This meant that the middlewares registered for the default namespace
were triggered in any case, which is a surprising behavior for end
users.
This also meant that the query option of the Socket on the client-side
was not sent in the Socket.IO CONNECT packet for the default namespace:
```js
// default namespace: query sent in the query params
const socket = io({
query: {
abc: "def"
}
});
// another namespace: query sent in the query params + the CONNECT packet
const socket = io("/admin", {
query: {
abc: "def"
}
});
```
The client will now send a CONNECT packet in any case, and the query
option of the Socket is renamed to "auth", in order to make a clear
distinction with the query option of the Manager (included in the query
parameters of the HTTP requests).
```js
// server-side
io.use((socket, next) => {
// not triggered anymore
});
io.of("/admin").use((socket, next => {
// triggered
console.log(socket.handshake.query.abc); // "def"
console.log(socket.handshake.auth.abc); // "123"
});
// client-side
const socket = io("/admin", {
query: {
abc: "def"
},
auth: {
abc: "123"
}
});
```
The value stored in the adapter will now be used, instead of
duplicating it in the Socket class.
Breaking change: Socket#rooms is now a Set instead of an object
Closes https://github.com/socketio/socket.io/issues/2890
Accessing the clients of a dynamic namespace throws because doing `io.of(/your-regex/g)` returns a namespace with no adapter and the clients methods tries to access `namespace.adapter.clients`.
This follows #3187, with a slightly different API.
A dynamic namespace can be created with:
```js
io.of(/^\/dynamic-\d+$/).on('connect', (socket) => { /* ... */ });
```
Previously, the protocol was not taken in account, which caused the following behaviour:
```js
io.origins('https://foo.example.com:443'); // ok as a string
io.origins(['https://foo.example.com:443'); // not ok as an array
```
Fixes#3190
So that the call to the `has-binary` method can be skipped. Usage:
```
// with binary data
socket.binary(true).emit("binary", obj);
// without binary data
socket.binary(false).emit("string", obj);
// call to hasBin
socket.emit("guess", obj);
```
Using a middleware could previously lead to a connecting client
receiving a connect event from the server before the server triggers
its own connect event.
Browserify doesn't support require.resolve, and as a consequence, makes nexe fail the compilation. This PR attempts to get the path of the socket.io-client file via path.resolve and falls back to the original require.resolve if this file cannot be found.
* fix(socket): Fixes socket.use error packet which drops nodejs due to nuances of Nodejs' EventEmitter
* fix(socket): Fixes missing error event on socket
* fix(socket): test fix, should listen for clientSocket instead of server socket
* minor update
That new flag will prevent the adapter (redis) from publishing the emit to the pub/sub server.
When several instances of a server receive the same event from a third party (not from a client), each server instance broadcasts the event to all his clients. With the local flag, and the change in the redis adapter, each server instance send the event only to his client, so each client receive only one unique event.
