Store custom client ID on Agent/Connection ID

[alecgibson]

It can be useful to identify which connection submitted what operation.
This is already possible to some extent by tracking the ID randomly
generated when instantiating Agent.

However, this ID obviously changes on every connection, and bears no
relation to the actual client that is connecting.

This change allows the client to specify some ID when connecting, which
will be concatenated on to the agent's ID like this:

<randomId>:<clientId>

Keeping the randomId ensures that the IDs remain unique, and
concatenating the clientId allows the consumer to later determine
which operations were submitted by the client that matches that ID, by
checking the src field stored on an operation.

[coveralls]

Coverage increased (+0.002%) to 96.494% when pulling feeb831 on alecgibson:custom-agent-id into 762e05d on share:master.

[coveralls]

Coverage increased (+0.002%) to 96.494% when pulling 849e615 on alecgibson:custom-agent-id into 762e05d on share:master.

[gkubisa]

Looks good to me. Could you update README.md before I merge (into https://github.com/teamwork/sharedb), please?

[alecgibson]

@gkubisa I've added a bit more documentation for Backend.listen. I've also inverted the order of the ID. The custom ID is now prepended instead of appended, so that if the underlying datastore has an index on the src field, you can easily group and fetch ops by a single client.

[gkubisa]

Nice, thanks @alecgibson 👍 It's merged and published as @teamwork/sharedb@v1.3.0.

[gkubisa]

It would be great, if the remote src was reported in create, op and del events... currently we always get false. How do you access the clientId on the client side, @alecgibson ?

In my opinion the above events should be emitted with an Event object, rather than individual params for op, src, etc. This would be much more flexible, however, it would require a major version bump.

[alecgibson]

@gkubisa this isn't to be confused with the (other) source on Doc events. I've never been very sure of what the purpose of that one is apart from figuring out which events have been fired from which clients.

The intended use case for thissrc modification is to get some client-identifying tag into the src field stored in the database (which is currently just a random Agent/Connection ID).

[gkubisa]

Grand, I might look into exposing it in the client API at some point.

[alecgibson]

Yes, that would make sense. My use-case is really only about dumping them into the database for retrieval via Mongo (outside of ShareDb), but they should be pretty trivial to extract again, too at the other end. I thought I wouldn't implement that end, because I don't really know what would be required.

[alecgibson]

As we discussed in the PR meeting, I'll close this in favour of just storing this on metadata in the middleware.

If anyone does want this sort of functionality in the future, we discussed that the best option is just to let consumers pass in a function that generates an ID, to give more control to them.

[curran]

How would the equivalent middleware code look?

Might it be possible to convert this PR into a reusable middleware package?

It would be a shame to see this work go to waste, especially if it address a common problem.

[alecgibson]

@curran I need to implement this, so once I've done it I'll try to share a gist or something.

[alecgibson]

@curran for reference, this is roughly what the middleware looks like:

share.use('connect',(request,callback)=>{// Clone request to avoid mutation after connectionconstrequestJson=JSON.stringify(request.req||{});constrequestData=JSON.parse(requestJson);Object.assign(request.agent.custom,requestData);callback();});share.use('submit',(request,callback)=>{request.op.m.userId=request.agent.custom.userId;callback();});

I think it's probably too small to bother putting into a library.

[curran]

Awesome. Thanks!

[houshuang]

@alecgibson Hi, this looks like exactly what I need, but I need a bit more context to use it. My use case is that I want to identify a userid when logging in from the client, however for the life of me I cannot figure out how to pass the custom userId when connecting from a client? Your help would be much appreciated! I tried

constReconnectingWebSocket=require('reconnectingwebsocket');constsharedbClient=require('sharedb/lib/client');socket=newReconnectingWebSocket(shareDbUrl);_connection=newsharedbClient.Connection(socket,{userId: 'stian'});

but when console.logging the request in the middleware, it was undefined. And anyway I don't see any code in the client library which would pass any information along to the server?

[alecgibson]

@houshuang you need to pass the information in from the server side, so wherever it is in your backend code that you call share.connect or share.listen, you need to pass the user Id in there (eg by retrieving it through an authentication cookie or similar).

[houshuang]

Thank you very much for replying, but I still don't quite understand. I start up a listener on the server, and then each client connects individually directly with the ShareDB port, so how would the backend know, at the time the listener is started, which user is connecting from the front-end? I was expecting to be able to send this information from the front-end when connect()ing somehow.

…

On Mon, Oct 1, 2018 at 12:05 PM Alec Gibson ***@***.***> wrote: @houshuang <https://github.com/houshuang> you need to pass the information in from the server side <https://github.com/share/sharedb/blob/master/lib/backend.js#L137-L168>, so wherever it is in your backend code that you call share.connect or share.listen, you need to pass the user Id in there (eg by retrieving it through an authentication cookie or similar). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#224 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADwhwqqRPBiS3nBud-jzrwTSY13BHtAks5ugejPgaJpZM4VQ9cv> .

-- http://reganmian.net/blog -- Random Stuff that Matters

[alecgibson]

@houshuang on your server you should some code that looks something like this (from the README):

varWebSocketJSONStream=require('websocket-json-stream');// 'ws' is a websocket server connection, as passed into// new (require('ws').Server).on('connection', ...)varstream=newWebSocketJSONStream(ws);share.listen(stream);

Each websocket will be unique to the connecting client, which you are hopefully somehow authenticating when they connect. With that authentication information, you should have a handle on their user ID on the server, so you should be able to adapt the above to something like:

varwss=newWebSocket.Server();wss.on('connection',function(ws,req){// If you're using Express you'll need to use cookie-parser.constauthenticationToken=req.cookies.token;// Then you'll presumably need to do something with your token// to check what the user's ID is (eg db lookup, or parse JWT, etc.)constuserId=getUserIdFrom(token);conststream=newWebSocketJSONStream(ws);backend.listen(stream,{userId: userId});});