The problem with the cookies — handshake error when using

Our programmer made the site on the basis of engine Node.JS and on the local computer everything works perfect — and in their interactions with localhost and applications on the network. Place this creation on our server and put the whole list of modules that it uses. Not working...

Debriefing revealed that a script from a file calls from the server On the server, it calls the handler described in the following block of code:

io.configure(function (){
 io.set('authorization', function (handshakeData, callback) {
 // some code analysis

after the server gives the console message: "warn — handshake error" and the client returns the text of the "handshake error". The situation is repeated consistently during the test from a browser on the server itself and from its network.

Added in the authorisation process the JSON serialization parameter handshakeData and received on the server result:

Coockie: {"headers":{"host":"","connection":"keep-alive","accept":"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8","user-agent":"Mozilla/ 5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.66 Safari/537.36","accept-encoding":"gzip,deflate,sdch","accept-language":"ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4"},"address":{"address":"","port":3146},"time":"Tue Sep 17 2013 19:16:16 GMT+0300 (EEST)","query":{"t":"1379433566379"},"url":"/","xdomain":false,"issued":1379434576801}

But the developer working on his car in the headers still have cookies, and therefore the content handler authorization succeeds, warning is not generated and the web service is running:

Coockie: {"headers":{"host":"localhost:3000","connection":"keep-alive","user-agent":"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36","accept":"*/*","referer":"http://localhost:3000/","accept-encoding":"gzip,deflate,sdch","accept-language":"en-US,en;q=0.8","cookie":"auth.sid=s%3APjHB8aINSzgpvDqgPLtcwkSp.VVyPsLtWzyJKzooaePC2Yg1WaISVp5ew6x1e88jghly"},"address":{"address":"","port":44417},"time":"Tue Sep 17 2013 19:02:40 GMT+0300 (EEST)","query":{"t":"1379433760241"},"url":"/","xdomain":false,"issued":1379433760263}

I already miss the second day? It may need some specific settings for Express?
October 3rd 19 at 03:51
3 answers
October 3rd 19 at 03:53
sessions are stored where? line express.session(?)
express 2 or 3?
Express 3.
Configure the following:

app.configure(function() {
 .set("port", config.Server.port)
 .set("trust proxy", true)
 secret: cookieSecret,
 key: cookieKey,
 store: sessionStore,
 .use(express.static(__dirname + config.Server.staticPath));

- mariana_Considine commented on October 3rd 19 at 03:56
in the variable sessionStore that is? - Larry_Senger commented on October 3rd 19 at 03:59
There radishes.

Here is a listing of the initialized variables:

var express = require("express");
var connect = require("connect");
var http = require("http");
var cookie = require("cookie");
var redis = require("connect-redis");

var app = express();
var server = http.createServer(app);
var io = require("").listen(server);
var RedisStore = redis(express);
var sessionStore = new RedisStore(config.DB.Redis);
var sessionObj = [];

- mariana_Considine commented on October 3rd 19 at 04:02
pomeo, thanks for the direction to my investigations in the right direction.

Corny had to install the service of radish.
I naively thought that the radish is something like stxxl:map and he module for Node.js should suffice with a head. - mariana_Considine commented on October 3rd 19 at 04:05
October 3rd 19 at 03:55
Is there a cook in the browser at all?
If there is, it may not be delivered if the client and server are on different domains (or using https)? Dig into the side of headers, Access-Control-Allow-Origin and Access-Control-Allow-Credentials.

For completeness, put the headers of the request and response (them directly in the browser to see) and the domains of the client and the server.
Cookies in your browser is enabled, problems with surfing the Internet.
The client and server are problematic cords even when not on the same computer (remember that so, too, does not work), then in the same local network and turn to each other for IPS: (server) and (client). HTTPS is not used.

The first exchange of headers between client and server at connection time (before the start of the the following:

GET / HTTP/1.1
Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Pragma: no-cache
User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.66 Safari/537.36
Accept-Encoding: gzip,deflate,sdch
Accept-Language: ru-ru,ru;q=0.8,en-US;q=0.6,en;q=0.4

HTTP/1.1 200 OK
X-Powered-By: Express
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET,PUT,POST,DELETE
Access-Control-Allow-Headers: Content-Type
Accept-Ranges: bytes
ETag: "3867-1379421660000"
Date: Wed, 18 Sep 2013 08:49:25 GMT
Cache-Control: public, max-age=0
Last-Modified: Tue, 17 Sep 2013 12:41:00 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 3867
Connection: keep-alive - mariana_Considine commented on October 3rd 19 at 03:58
You crossdomain request ( and different domains).
Access-Control-Allow-Origin: * won't work if set Access-Control-Allow-Credentials: true. Try Access-Control-Allow-Origin: <a href="</code>."></a>. - Larry_Senger commented on October 3rd 19 at 04:01
Thank you for participating. The response was prompted by pomeo — it was the radish, but rather in his absence. - mariana_Considine commented on October 3rd 19 at 04:04
Unexpectedly )
Now everything is working? - mariana_Considine commented on October 3rd 19 at 04:07
Doubly unexpected about that data during the session he kept in another database system!
Yes, now it works.
Thanks again for your patience and participation. - mariana_Considine commented on October 3rd 19 at 04:10
I had a version that you just forgot when you develop to change the storage location of the sessions and left them in memory. Because there is clearly a problem with storing sessions. Developer run with NODE_ENV=development , and it all worked, and you ran the server with NODE_ENV=production , and you have not worked there although it spits in the console about it.
Then you wrote whatever you have radishes, wanted to offer go to memory and run with NODE_ENV=development, to exclude all possible problems with radishes. But you already own found.
In General, to express very difficult to look for errors, they get out there from very interesting places. For example the most popular is because of wrong order in the app.configure, you there is also a mess, but you got lucky =) - Victoria16 commented on October 3rd 19 at 04:13
October 3rd 19 at 03:57
I'm not sure what it is, but hypothetically, maybe Cooke is httpOnly parameter?
No. With browsers successfully surfing any other websites on the Internet. View my answers for pomeo and Anonym — I have answered more broadly with the headers and pieces of the server code. - mariana_Considine commented on October 3rd 19 at 04:00
I'm not sure what it is, but hypothetically, maybe Cooke is httpOnly parameter
And then, the browser cannot receive cookies, but the server is still in the socket can. - Larry_Senger commented on October 3rd 19 at 04:03

Find more questions by tags Socket.ioJavaScriptNode.js