More on .mac Comment Hacking: The Story So Far

Saturday, 2006-09-02; 11:21:00

Some clues on how the .mac commenting system works

(Note: thanks to a certain friend who helped figure out some of these clues.)

When adding a .mac comment to an iWeb page, you get a URL that's structured like this:

You can see that you can reconstruct the URL to the iWeb page to which the comments are attached, simply by taking the URL parameter, changing the un-encoding the "%2F"s (to slashes), and adding to the front of the URL. However, changing the URL parameter to an arbitrary URL doesn't work; for example I have a webpage at . But the comment URL simply produces a "This entry no longer exists. The entry may have been moved or deleted," error message by the .mac commenting system. Clearly an HTML page existing at the URL parameter isn't the only requirement for the commenting system.

If you delete/move/rename the HTML file for a valid weblog entry that accepts comments, the comment URL for that page will immediately change to the aforementioned error. This means that while a valid HTML file at the URL parameter isn't a sufficient condition, it is a necessary condition. You can even temporarily rename the file, access the commenting system and get the error message, rename the HTML file back, and the commenting system will once again accept comments at that URL -- even comments that were entered before the HTML file was temporarily moved will be preserved.

So it looks like there's some initial thing that iWeb does that informs the .mac commenting system that it should accept comments at a specific URL.

If you poke around in the HTML for the add a comment page, you'll find this URL: . This is a JavaScript file that at least partially powers the commenting system. If you look around in it, you'll find this:

// Create new JSON script element, new script element will call comments.update() 
JSONScript.setAttribute('id','view_' + c.view); 
JSONScript.setAttribute('src',location.pathname + '?wsc=entry.js&ts=' + new Date().getTime()); 

From this you can construct a URL that will get comments in their "raw" form from the commenting server. For example, the URL will show you the raw form of the comments on the previously linked iWeb page. Somehow the wsc parameter is causing something to handle the URL specially -- if you just go to , you'll get the entry page, but with a / at the end rather than the ?wsc or nothing. You can attempt to do this for any old URL, but you'll either get an error ( ) or nothing at all ( ).

I'm not sure where this entry.js file is. There is a JavaScript file that's present in the folder containing related files for each entry, but it's not named "entry.js". For example, the above-referenced iWeb page has the associated JavaScript file at . One of these JavaScript files is created for each iWeb entry. It doesn't seem to be particularly useful, though -- it just formats the comments and adjusts for browser quirks, it seems.

A couple other related JavaScript files: DMHTTPConnection.js , composeComment.js , commentManager.js , and of course the aforementioned comment.js . I don't think anything except the comment.js script is really relevant.

Since you can't even access the "Add a Comment" page for any old URL (gives you the "entry is moved or deleted" error), this leads me to believe that iWeb must contact the server and do something to tell it to accept comments at a certain URL before it even copies the files to your iDisk to publish your weblog. In that vein, I decided to do some packet sniffing on iWeb. Specifically, I used the command:

sudo tcpdump host

The sudo is required because the program tcpdump (should be included with every copy of Mac OS X) needs to run with admin privileges. I also told it to filter out any packets that aren't to the server. I get a bunch of lines like this:

00:09:16.023634 IP > F 2593890109:2593890109(0) ack 692842204 win 44888 <nop,nop,timestamp 671722126 1477866389>
00:09:16.040477 IP > . ack 1 win 16384 <nop,nop,timestamp 1477868038 671722126>
00:09:34.757299 IP > S 3697992021:3697992021(0) win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 671722163 0>
00:09:34.771926 IP > S 631969074:631969074(0) ack 3697992022 win 8190 <mss 1460>
00:09:34.772015 IP > . ack 1 win 65535
00:09:34.772606 IP > P 1:112(111) ack 1 win 65535
00:09:34.792209 IP > P 1461:2157(696) ack 112 win 8190

Not exactly helpful either. But there's a way to dump all the raw packet data to a file. Use the command:

sudo tcpdump -w /path/to/desired/file host

instead. After doing so, and opening the resulting file in a text editor, I get things like this:

iWeb to server packet code

There are small bits of human-readable code dispersed throughout the file, but most of it is that unuseful trash. The above snippit does indicate that an XML request is sent to the server, though. It also indicates that there's a different WebObjects app listening on the server. You can access it at . You'll notice that if you misspell it to WSDomments.woa, it'll say that "The requested application was not found on the server." So there's definitely a WebObjects app listening at that URL. The only problem is that I can't figure out any parameters to send it. It does occur to me that "WSComments" is similar to the "wsc" parameter to access raw comments, but that doesn't really help much. (Maybe WS stands for WebServer?)

I suspect that there's more hidden in the raw packet data from tcpdump, I just don't know how to access it. Does anyone know how to decode that kind of data, or how to get tcpdump to write all the data in a human-readable format? If you do, send me an e-mail... enetation is probably going way too slow to get any sort of use out of the existing comment system anymore.

Technological Supernova   Tips   Older   Newer   Post a Comment