0

I'm using a third party authentication service along with a guard on my on_connect method to handle user authentication against my socket connection. This is working as I had hoped, but I have noticed a couple things I am unsure how to solve.

The first thing is, what is the suggested work flow for handling expiring or expired tokens? The issue I see currently is that I do not see how to replace the token introduced during the connection event with a new one without disconnecting and reconnecting using the new token.

The other thing is, Why does a user that is prevented from getting a connection through the use of raising a ConnectionRefusedError, still get a session id assigned and no notification of the connection failure? To test this I manually created a client using python-socketio, and did an invalid connection attempt and then printed the value of sid.

Galax Womack
  • 23
  • 4
  • 1
    For the token, normally the token is checked only on connection. If you need to interrupt a client when their token expires you can add a token expiration check each time the server receives an event, and call `disconnect()` when the token expires. – Miguel Grinberg Sep 18 '20 at 18:53
  • The problem with the connection failure is strange. If you are using the latest releases of python-socketio and python-engineio, then the best would be to file a bug in python-socketio and include an example to help me reproduce the problem. Thanks! – Miguel Grinberg Sep 18 '20 at 18:54
  • @Miguel In relation to your first comment. That is exactly how I am handling it at the moment. But I would also like to offer the client the opportunity to refresh their expiring token. Then let them start using the new token before the other events disconnect them. This way they don't miss events they should be listening for which might occur while they are doing the token cycling. – Galax Womack Sep 18 '20 at 19:38
  • 1
    I honestly don't see what additional security you gain by having the token checked/renewed on every event. If the user connected and you checked the token at that time, in my view there is no point in checking the token again in the middle of the connection. It would only make sense to do a recheck if the connection breaks and a the client reconnects. Don't forget that the point of checking a token is making sure the client is who they say they are. Once you confirm that you should be okay until the connection ends. – Miguel Grinberg Sep 19 '20 at 10:39
  • That is a good point. Right now I am using a third party that manages the tokens. I query them to get additional information I need for certain events. I can only get information on a valid token; but I don't have to continue to do that after I get the information on connect. – Galax Womack Sep 20 '20 at 03:40

0 Answers0