Reconnect issue

[David Milligan]

Hi Guys,

I have a socketio server which authorizes a connection based on a timestamped token passed in the query string.  Following a disconnect client side the client attempts a reconnect and as the token is expired the connection is refused.  Is there some 'trick' that will allow the socketio server to detect that this is a reconnect so I do not have to regenerate a token which is not really an option.  Below is my configure function,  I have tried checking the authorized property in the handshake, but to no avail.

David

   socketio.configure(function () {

     socketio.set('authorization', function (handshakeData, callback) {

       var queryString = handshakeData.query;

       if (handshakeData.authorized || (tokenHandler.decryptToken(queryString) == true)) {

         handshakeData.authorized = true;

         logger.info("Connection authorized from " + handshakeData.address.address + ":" + handshakeData.address.port + " ProcessId:" + process.pid);

         callback(null, true);

       }

       else {

         logger.info("Connection refused from " + handshakeData.address.address + ":" + handshakeData.address.port + " ProcessId:" + process.pid);

         callback(null, false);

       }

     });

  });

[Garry Taylor]

Hi David, you could go down the same route that OAuth does and store a list of tokens that will grant refresh rights.

 

For example:

ListA: Active tokens being used

T1

T2

T3

ListB: Allow refresh token

T1

T2

T3

T4

T5

 

Steps

Use connects with a token (T2), he is fully authorised.

Use disconnects

T2 is removed from ListA

User reconnects with token T2

User is not authorised so check against ListB

Token T2 existing in T2

Create new token T6 and update listA and ListB

 

Note you will need to get the socket to request a new token using T2 as a temp token key

You will also need to expire ListA and ListB based on acceptable values

 

The trick here is to allow tokens to live even after the session is disconnected, but do not allow them to live forever.

 

Garry Taylor
Head Technical Developer

 

The information contained in this message is confidential and may be legally privileged.  This email is for the use of the intended recipient (s) only.  If you have received this email in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this email without the author's permission.

We have taken the precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own checks on any attachments to this message - we cannot accept any liability for any loss or damage caused by software viruses. Any opinions expressed in this message are those of the sender only and do not necessarily represent the views or opinions of Fluent Money Limited or any associated companies.

--
You received this message because you are subscribed to the Google Groups "Socket.IO" group.
To unsubscribe from this group and stop receiving emails from it, send an email to socket_io+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[David Milligan]

Thanks Gary,

The problem I have is tokens are generated on another service accessible from the customers webserver only.  I assumed/hoped that a reconnect would retain any handshake data from the initial connection but it seems not.  Looks like I may have to look at another structure for the token, maybe use the 
remote_addr in generating tokens.

David.

[Garry Taylor]

You could use Amazon AWS dynamoDB to store a copy of the tokens, then update the dynamoDB table to stay in sync with the tokens. However this approach involved updating the existing client facing webservice and adding the Amazon Node Module to access the table.

 

I am sure you are aware but you need to be very careful when using Auth tokens. I recommend using a Auth Distributed Service that handles tokens across different services. Then both the webservice and Node would use the same token based security. Lot of work but worth it in the end.

[David Milligan]

Hi Again Garry,

Thanks for the input, you say ' I am sure you are aware but you need to be very careful when using Auth tokens.'  If you can spare the time to elaborate on this a little I would be very grateful as this is the my first implementation of authentication using tokens.

David