Migration from Socket.io about socketcluster HOT 5 CLOSED

Yes, you can do handshake authentication or you can also authenticate events individually. You should read the section on Authentication on the main GitHub page for details.

Binary transport should be supported but an ArrayBuffer sent from the client should arrive as a base64 string on the server and a Buffer sent from the server should arrive as a base64 string on the client. This is partly because a lot of browsers still don't support ArrayBuffer and I felt that it's better to have a consistent interface than have to do browser checking.

EDIT Actually, ideally, they should arrive as a Buffer on the server.

It sounds like you might have found a bug because you definitely shouldn't be getting an empty response. I will check this later today.

from socketcluster.

Actually, the ArrayBuffer seems to be being replaced by an empty object.

socket.send('example', {
  name: "test",
  data: ArrayBuffer
});

turns into:

{
  name: "test",
  data: {}
}

And:

socket.send('example', ArrayBuffer);

turns into:

{}

I'm not sure how I missed the authorization section of the readme, but after having gone through it, I am getting an empty req.session in the wsServer.MIDDLEWARE_HANDSHAKE example.

scServer.addMiddleware(scServer.MIDDLEWARE_HANDSHAKE, function (req, next) {
  req.session.get('isUserAuthorized', function (err, value) {
    if (value) {
      next();
    } else {
      next('Session ' + req.session.id + ' was not authorized');
    }
  });
});

Is socket.session.set('isUserAuthorized', true); intended to be placed on the connection event? Seems that the MIDDLEWARE_HANDSHAKE runs before the connection event.

from socketcluster.

Yes, MIDDLEWARE_HANDSHAKE runs before the connection event (the callback receives a HTTP req object not a socket).

All socket objects have the session object attached to them, this should also be true for every HTTP requests (I.E. req.session) - But it appears to not be the case - This is a pretty urgent issue - I should be able to have this fixed by tomorrow.

To clarify things: To do handshake auth, you would have to authenticate the user over HTTP first and then you would check the session within MIDDLEWARE_HANDSHAKE (using req.session). - It's basically useful for preventing someone from establishing a persistent connection with the server (It's more for efficiency purposes - You still need to use EMIT, PUBLISH and SUBSCRIBE middleware for more control - See link at bottom).

So basically until I fix this bug, you can't effectively prevent sockets from establishing a connection (because you don't have access to the req.session object which you need to set auth tokens).

Once the connection is established though, you can still block connected sockets from listening, emitting and publishing certain events. I will have to update the documentation on this, but in the meantime, you should look at this blog post I wrote a while ago:

http://ncombo.wordpress.com/2014/08/22/full-stack-pubsub-with-socketcluster/

from socketcluster.

I fixed the first issue with the req.session being undefined. With the latest SC version on npm, you should be able to store/manipulate session data through HTTP requests before the realtime connection is established.

The ArrayBuffer issue is the next priority. You should expect a fix within the next few days.
Right now, you can send buffers to the backend by running this on the client:

socket.send(buffer);

and you will receive it as a 'raw' event on the server:

socket.on('raw', function (data) {
    console.log('RAW DATA:', data);
});

Note that whenever you call send() on the client, you will receive the data from a 'raw' event on the server (you can send raw strings too). Unfortunately, this isn't always ideal since we are just sending raw data - It would be nice to be able to emit the buffer as part of an event and within an object like this:

socket.emit('someevent', {
    message: 'This message contains a buffer',
    buffer: ArrayBuffer
});

That will be my focus in the next few days.

from socketcluster.

Ok, the bug with not receiving ArrayBuffer has been fixed.
Binary is now supported but note that when emitted as part of an event, ArrayBuffers will be converted to base64 objects of this form:

{
  base64: true,
  data: "YWFhYWFhYWFhYQ=="
}

This is different (and slightly less efficient) than Socket.io where binary buffers gets passed raw as 'attachments' along with the event data. There are two reasons why the cast-to-base64 approach was chosen:

1. You get a consistent object (containing the base64 string) regardless of browser (whether or not it supports ArrayLists or Blobs or neither).
2. It's much simpler to handle base64 strings on the backend especially when it comes to scalability. Raw binary attachments would add a level of complexity - Developers will have to figure out how to transfer this mixed binary/string data across multiple remote machines - It would require a new protocol. Also, having it as base64 makes it compatible with more database engines.

I'm not opposed to moving to using raw binary attachments in the future, I just feel that the added complexity is not worth the performance advantage right now (at least until browser and NoSQL support for binary types improves). It mostly depends on consensus and common use cases so I will keep an eye on this.

from socketcluster.