undocumented XML-RPC methods

[jfelectron]

Some googling and testing revealed the following undocumented XML-RPC methods, which expose a number of nice functions from the client side.

All are in the LJ.XMLRPC namespace of course:

getfriendspage
sendmessage
setmessageread
getinbox
addcomments

These were gleaned from: code.livejournal.org/trac/livejournal/browser/trunk/cgi-bin/ljprotocol.

Comments

[jfelectron]

@pauamma: Err...yes. I based this erroneously on there being a lot of old commits.

@duskwuff: Yes getfriendspage is incredibly basic, but its better that screen scraping!
The method could easily be expanded to include other useful stuff.

Yes, the random base64 encoding is annoying. Its not clear to me exactly what is being encoded. Can you get anything usable out of decoding? Is it an image file?

[jfelectron]

Ooops...yeah. The xmlrpc client I use for testing was barfing on the base64 and returning some strange array of numbers, which I failed to see was not base64 :).

You're right, its just the raw HTML of the post body that gets encoded. Its a total mystery what triggers this.
I trolled through the code to see if I could see where the base64 is happening, but I couldn't find anything obvious.

[jfelectron]

Yeah...my javascript XMLRPC client was hanging when it got to the tag because it wasn't 'trained' to handle that. I had to add that and then pass the base64 encoding string a base64/utf-8 decoder to get out the HTML text. Its a total mystery what triggers the encoding.

[soph]

I know this is an old post, but I just came across this comment and I would suspect that it might have been if the entry had the "unknown8bit" prop set, meaning it was either posted from a client that didn't know UTF-8 or was posted before the LiveJournal site was converted to UTF-8.

That's just a guess, though. (It might not even still be happening; I haven't tested.)

[jfelectron]

LJ randomly encodes posts from RSS feeds like Flickr or even posts created using the web editor. There is no particular rhyme nor reason to it. UTF8 strings are also based64 encoded, but this is expected.

[soph]

I would expect the opposite, actually. Pure UTF-8 should be fine coming down the wire, especially if version 1 of the protocol is used, because that mandates UTF-8 in the protocol over any other character set. And the decoded base64 is still going to be UTF-8 in the end, so...