Sunday, June 27, 2010

The Best Code

‹prev | My Chain | next›

One of the two bugs that I investigated yesterday was that reloading the game page was not refreshing the comet session. The game continued to use the old comet <iframe> even though the browser had closed it.

As a temporary fix, I removed the conditional for establishing new players (i.e. don't add a new player if the player is already registered). That introduces yet another problem: it is now quite easy to impersonate other players.

Today, I would like to get to a point at which browser reloads re-use the player already in the game, but only that player can re-attach a comet <iframe>. I began fiddling with this last night, but the solution towards which I was driving involved a complex server-side md5 signature being stored and sent back to the browser. Fab.js (by way of node.js) can easily support crypto signatures:
var crypto = require('crypto');
var data = "asdf";
crypto.createHash('md5').update(data).digest("hex");
// '912ec803b2ce49e4a541068d495ab570'
The browser would then cache the md5 signature such that it could survive a page reload. I was thinking about storing the signature in the <iframe> URL or investigating whether or not Javascript object state could survive reload. I wasn't sure how, but it was going to be awesome.

A day later, the best code is the code that I didn't write.

Today, I remembered that browsers have been able to store state in cookies for the better part of a lifetime. To set a cookie in fab.js, I ought to be able to Set-Cookie along with the other HTTP headers that I am already setting:
function init_comet (app) {
return function () {
var out = this;

return app.call( function listener(obj) {
if (obj && obj.body) {
out({ headers: { "Content-type": "text/html",
"Set-Cookie": "MYFABID=123456789" } })

({body: "<html><body>\n" })
//...
}
return listener;
});
};
}
At some point, I will replace that dummy session ID with the MD% sum code. For now, I keep it simple and would like to make sure that I really can set cookies. Sadly, when I access this resource, I do not see the cookie being send back to the browser:



Hrm... Checking in curl, I see that the cookie is being sent back:
cstrom@whitefall:~/repos/my_fab_game$ curl -I http://localhost:4011/comet_view?player=foo\&x=250\&y=350
HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: MYFABID=123456789
Connection: keep-alive
Transfer-Encoding: chunked
Am I somehow messing up the syntax? I check in Firefox and there I actually see the cookie being sent back and forth. Is Chrome rejecting my cookie for some reason? Is my Set-Cookie too old fashioned in that it is not sending any other attributes?

Nope. Nothing like that, the cookie is being set, but Chrome's resource inspector is simply not showing it. I eventually track down the cookie in the storage inspector:



Chrome is nice, but there are definitely reasons to stick with Firefox/Firebug. So I really do know how to set cookies in fab.js. It took me quite a while to track that down, so I will have to defer actually doing something with those cookies until tomorrow.

Day #147

No comments:

Post a Comment