|Authentication Style Question (And Request)
||[Jul. 25th, 2004|11:00 pm]
LiveJournal Client Discussions
|||||U2 - Alex Decends into Hell for a Bottle of Milk||]|
Hi, I am working on a Java Package to offer all the functionality of a Live Journal Client in a nice and easy way. Anyhow, I have been looking at the protocol documentation and was basically just wondering on opinions of other developers and what they would consider good and bad style. If this sort of post is 'wrong' here, please inform me - I'm kinda new to LJ, especially Communities, and don't know the etiquette yet.
Authentication - Am I correct in believing that, unless you use the 'cookie' method of auth, then you are expected to send the auth details with each LJ request? Unfortunately, the Apache Xml-Rpc library for Java doesn't support cookies, and I don't feel like hacking the code unless I have to - so that means 2 requests per 'LJ Request' as it were (challenge/response) - is this considered OK?
Are there any plans to add the option to send session cookie with the RPC call instead of as a POST header? Since you can send any other authentication method with the call, it seems a shame that you cannot send the session cookie in the same manner. And of course, it means that xml-rpc wrappers that hide the POST request from you cannot use the cookie method. Is there another LJ that I should request this update in, or can I go through a CVS and put forth a suggested update myself? I guess it shouldn't be that hard - I would imagine all these vars are handled around the same place.
Many thanks, and apologies again if ant of this is 'bad etiquette'. Consider it also a kind of introduction too!
Working hard on WingedMonkey - A LJ Client Java Package
Typically if you're going to do a number of requests in a row, you fetch the challenge at the same time as your regular request. So for the first request, you'd need to fetch a challenge by itself, then for subsequent requests you request a challenge in addition to whatever work you are doing in your regular request.
Of course, each challenge has a specific lifetime, so if it has fallen off, you'll need to fetch a new one. I personally prefer challenge/response, I found it very easy to implement and it seems to me to be the most secure.
As far as cookie authentication goes, I'd say it's unlikely your suggestion will be accepted. Since the interface uses HTTP as a transport, and HTTP supports cookies, moving that method of authentication into the body of the request doesn't make much sense.
Are you sure that you can't add a header manually to the underlying HTTP request using the Apache XML-RPC library? That strikes me as pretty poor design.
Ahh - I see the cunningness behind the first method, but have to say that I would be most likely to implement the standard challenge/response every time thing - for ease of coding.
As for passing the cookie with the request, I didn't mean for it to replace the sending of the cookie through HTTP, just to be an alternative option for it getting there. But yeah, there probably aren't many RPC clients this restrictive.
As for Apache's XML-RPC library not supporting your own HTTP headers - unfortunately not. You'd think it would be logical for them to just provide a raw 'addHeader(line)' function - but nope. Apparently, they are working on adding more functionality, but it's been a while since the last update. I guess the JavaX RPC support is growing - but it's VERY confusing and convoluted for a simple client.
...I would be most likely to implement the standard challenge/response every time thing - for ease of coding.
That's certainly easier, but it's not particularly efficient. The general philosophy of LiveJournal's client policy is "cache as much as you can", which by extension means keeping the number of requests down.
I see what you're saying about the headers bit, but again, I would suspect that folks would be reluctant to include that and thereby complicate the protocol (and the handler code in the LJ codebase). Too bad about the XML-RPC interface, that's pretty lame :(
Hmm... I'm using challenge/response (and the flat interface). I am doing a "mode=getchallenge" request before every request. Are you saying it is possible in future to send 2 modes with each request? Or does the technique of getting the challenge with another request only work with the XML-RPC interface?
Hmm, after a little testing it seems that you can't do what I'm talking about with the flat interface.
To be honest, I haven't tried it with the XML-RPC interface either, but my understanding is that it's possible from talking to people and observing existing client behavior.