Ws: Is there a way to know the page path from where the ws connection is being called?

[shacharz]

e.g: A page www.mysite.com/path/to/page.html loads a script that starts ws connection with ws server
Can we know in the ws server what's the path/to/page.html is? - The referrer that is.
All I see is origin/host and the url of the actual ws connection.

[tmpfs]

Look at ws.upgradeReq.url in the client connection within the server connection event.

[shacharz]

What do you mean 'client connection within the server connection event'?
When ws.on('connection',function(socket){
...
});
is triggered, I looked at socket.upgradeReq.url and that's only the url of the socket request not that page path.

[tmpfs]

I mean what you posted ws.on('connection',function(socket) so in your case socket.

The upgradeReq is an IncomingMessage, please read the docs:

http://nodejs.org/api/http.html#http_http_incomingmessage

And in your case it seems you also need to read:

http://nodejs.org/api/url.html

[shacharz]

Ok so if the upgradeReq is an incomingMessage - there's no way to retrieve the page url from it.

I have no problem with parsing, but the information is just not there.

Just clearing out, the script that starts the ws connection can be on a page like I aforementioned and the ws url will be ws://differentServer.com and the upgradeReq object's url will show only the differentServer.com url since it's an incomingMessage for the ws url.

[tmpfs]

Have you tried upgradeReq.headers.referer?

[tmpfs]

If not then your client code can add the referrer as a query string parameter and the server can extract if from that.

[tmpfs]

Are you going through a proxy? You might need to proxy some headers.

[shacharz]

No proxy, There's no referrer header in the upgradeReq.headers.
Only origin, host.
Yea the query string is always the last choice.

[tmpfs]

Shame the spec doesn't allow setting headers to be sent in the upgrade request: http://www.w3.org/TR/websockets/#the-websocket-interface

And I guess browser implementations are not sending _referer_ with the upgrade request which seems like quite a major oversight to me.

The other alternative is to perform an initial handshake with the server that sends this info.

[tmpfs]

Ok quickly, this is the third option and the best way, it is how I do it.

I assume that the reason you want this information is to identify the application making the request and branch the code.

You must have access to the client code which I assume you do. When you connect to the server, do not connect to the root (/) connect to an id for your application, you can use document.location.pathname if you like, ie:

http://websocket-server.com/path/to/page.html

Provided you have not added a path option when configuring the server the upgrade request will be handled.

Implement the verifyClient option as a function (use arity of 2 for asynchronous handling), quick and dirty sketch for you:

var url = require('url');
function verifyClient(info, cb) {
var uri = url.parse(info.req.url);
// now you have the information you want
var referrer = info.origin + '/' + uri.pathname;
// should also verify `info.origin` here
// and invoke cb(false) if it is a bad origin - the websocket connection will
// not be established

// stash the info in the upgrade request, access it later via: ws.upgradeReq.referrer
info.req.referrer = referrer;

cb(true);
}

Now pass verifyClient as an option when creating the server and you are good to go, hope that all makes sense.

Voila!

[shacharz]

Thanks, actually I wanted it for analytics purposes.
I already have an id based verification method much like you stated.

Looks like currently, there is no information about the page path inherented into ws.
And we'll need to transfer it via query string/path to websocketserver or first message of sorts.

Thanks again for the help.

[bradisbell]

FYI, ws.upgradeReq is now undefined...

[diegoddox]

You can find this information on the req

wss.on('connection', (ws, req) => {
  console.log(req.url, req.headers);
});

[shacharz]

wss.on('connection', (ws, req) => {
console.log(req.url, req.headers);
});

That's incorrect, the url is the url of the websocket request not the page, and the referrer is not being sent as a header by browsers.

see https://github.com/websockets/ws/issues/347#issuecomment-66106654 to work around

[fedd]

That's really a strange solution that the websocket connection doesn't carry information about the referring page by default. Websockets are normally open from a page, and an application should be able to provide a page-specific service for that page, for example, some news regarding an entity that page is about.