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=350Am 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
HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: MYFABID=123456789
Connection: keep-alive
Transfer-Encoding: chunked
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