Preliminary Investigation into Securing Faye Messages

‹prev | My Chain | next›

I am doing some quick investigation of faye messages tonight. I would like to explore the possibility of ensuring that faye messages in my (fab) game describing player activity can only come from the client that originally added the player to the room. Right now there is nothing player Bob from telling the world that player Fred moved to coordinates -100,-100.

My first stopping point in my investigation is tcpdump. Maybe faye is already sending client identifying information along with its messages. Sure enough, it looks as though it is:

cstrom@whitefall:~/repos/my_fab_game$ sudo tcpdump -i lo -X -s 0 port 4011
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 65535 bytes
21:35:18.952622 IP whitefall.local.43436 > whitefall.local.4011: Flags [P.], seq 1644034536:1644034678, ack 1642986690, win 770, options [nop,nop,TS val 25728832 ecr 25722550], length 142
        0x0000:  4500 00c2 6ec4 4000 4006 46f5 c0a8 0196  E...n.@.@.F.....
        0x0010:  c0a8 0196 a9ac 0fab 61fd f9e8 61ed fcc2  ........a...a...
        0x0020:  8018 0302 8531 0000 0101 080a 0188 9740  .....1.........@
        0x0030:  0188 7eb6 005b 7b22 6368 616e 6e65 6c22  ..~..[{"channel"
        0x0040:  3a22 2f70 6c61 7965 7273 2f6d 6f76 6522  :"/players/move"
        0x0050:  2c22 6461 7461 223a 7b22 6964 223a 2266  ,"data":{"id":"f
        0x0060:  7265 6422 2c22 7822 3a32 3833 2c22 7922  red","x":283,"y"
        0x0070:  3a32 3030 7d2c 2263 6c69 656e 7449 6422  :200},"clientId"
        0x0080:  3a22 3139 3164 7531 6731 7432 6536 6b6d  :"191du1g1t2e6km
        0x0090:  3132 6233 3678 6f61 3831 3031 3122 2c22  12b36xoa81011","
        0x00a0:  6964 223a 226f 3265 7462 6e6f 386a 3469  id":"o2etbno8j4i
        0x00b0:  7031 3971 6c7a 6f31 6c6c 7479 6779 227d  p19qlzo1lltygy"}
        0x00c0:  5dff

I tend to doubt that this client information is sent along with the message for subscribers to use. Before I check, I dig through the faye client object to see where that clientId attribute might be. Unfortunately, I do not find it:



That _0 attribute is completely different than the ID that I saw in the tcpdump output. Even if it were the same, it feels like a private attribute and I see no public methods that would suggest that they describe the client ID.

That seems to be a dead-end. It may seem like sour grapes, but I doubt that the server would have had access to that client ID anyway, so what to try? It is possible to accomplish what I want here?

After digging through the faye site a bit, I rediscover documentation about security code locking down channels with a security code. It occurs to me that I might be able to do something similar, but with messages. A faye extension in the client can calculate a security code when the player first enters the room and embed it in an ext attribute of the message. The server can then extract that ext attribute and check it against the value that it has stored in the local player store. As long as the two match, the server allows the message.

The only thing that might not work there is reloading the page (how to make the code unique to a player, but survive browser reloads? cookies?). I will pursue this more tomorrow.


Day #199