I’ve tried formatting the headers table in a few ways such as:
auth.token abc123xyz
auth {“token”:”abc123xyz”}
Authorization Bearer abc123xyz
None of these have worked, and if I remove the auth checking entirely and comment that portion of the server code out, it connects fine and I start receiving the event messages I’m expecting. We need to have authorization on the socketIO server though.
Does anyone have suggestions on what I’m doing wrong as far as feeding the headers for that nested token value into the socketIO DAT?
The first input is currently always formatted as key-value pairs for the extraHeaders option, although we should detect and explicitly use the auth option when it’s specified in the input. I will change that.
As a work-around for now, you could grab and verify the client auth header from the headers option using socket.handshake.headers option on the server-side, but I do understand that this is non-standard in v3.0+.
Thank you so much for the quick reply and explaining which option the input was configured for. That solved it for me to request those changes to the server-side code.
Also that would be awesome for the future to have the operator detect or have some kind of handling for the standard auth option headers.
I’m glad that solution works for you in the meantime.
I’ve gone ahead and added two additional inputs to the SocketIO DAT: one for query parameters (which also weren’t exposed), and one for Authentication. Both are to be structured as tables with two columns representing key/value pairs, and in your case that would mean one column with token and one column with abc123xyz. This will be in the next official build we release: 2025.31950+.
Much appreciated! I noticed the update to the operator’s documentation already and looking forward to those updates. Thanks again for the update and support.
