-
Notifications
You must be signed in to change notification settings - Fork 10.1k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Authorization and handshake errors #545
Comments
If you pass null, false to the callback, you will get a 403. What do you think? |
+1 |
This is still the case in 0.9.6. It's not possible to tell the client why the handshake failed (server full? incorrect user/pass? invalid session?). The only thing the client ever receives is "handshake error". |
+1 |
Any chance for this handshake custom error propagating to the client? Thanks. |
👍 for this |
+1 for this |
one more +1 |
+1 |
+1 for this |
+1 for me too please |
+1 |
2 similar comments
+1 |
+1 |
The documentation appears to be wrong on this, but I've found that it is possible to have custom error messages. You just need to assign them ids so the parser can serialize them efficiently. Server
Client
|
+1 I want to kill myself |
Ok guys it's been 2 years since this bug has been noted. I found the solution (for my case). In my client side I had var "socket = io.connect('http://localhost:8080');" and it's works only if you put localhost:8080 in your browser. I changed it by "var socket = io.connect('http://127.0.0.1:8080');" and now it works with localhost:8080 and 127.0.0.1:8080 in your browser. It's clearly a bug, why socket.io should accept address mapping just in one way? localhost is localhost and is the same as 127.0.0.1 I hope I'll help some people, because it took us many days to find it. |
+1 for provide more detailed (handshake) errors for js client. |
koenigsbier's comment was the most helpful. having "http://localhost:8000" was producing handshake errors when I ran off my VPS. However, when using "http://127.0.0.1:8000" or my "IPAddress:8000" there is no handshake issue. I would like to see this fixed or at least noted in some documentation. |
The handshake error message is too generic and we can't pass more information if we want to display a more detailed error message on clients. Right now the log.warn is displaying enough detail in the server console. However clients can't access it. With this fix we can now send detailed error messages using callback("Session Invalid",false) resulting in "handshake error Session Invalid" on the client. Fix for the following issues: socketio#545 socketio#331
Using socket.io 0.8.4 from NPM, I'm struggling to get global authorisation working, so it can be handled on the client side. Using modified code from the Wiki, I'm checking for the existence of an Express session cookie and 'unauthorizing' the client if it doesn't exist.
my app requires a session cookie (from connect), so if the session cookie isn't present (because, perhaps, it has expired), I want to flag the io.authorization as failed.
The problem seems to be that calling
callback(error, false)
returns a 500 error to the browser, so it can't be handled client side. Surely this is incorrect as this can't easily be handled by the client?The example on the Wiki shows using the
socket.on('error')
event to handle this but that doesn't get triggered...or is the example on the Wiki out of date?
I also see that even though authorisation is 'failed', I still see a
debug - authorised
message in the debug log - which is why I think this might be a bug.Also the Wiki states that there are 3 possible response codes for a handshake: 401 Unauthorized, 503 Service Unavailable, or 200 OK.
This appears to be incorrect as both 500 and 403 responses are possible.
The text was updated successfully, but these errors were encountered: