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.

A random thought of mine, barely related to this... Is it normal for the lj.net client to allow me to edit this post? because I selected lj_clients as the journal i was looking at in journal manager, I can see posts... but the thing is that they aren't written by me... I am tempted to add something identifying the fact that I can change it, just to see if the change will succeed, but this is just straight odd... I would have assumed that it would only give me access to edit my posts or am I missing something in either how much access I have here or in how lj.net works...

Let me know what I should do here...

Also I posted an entry, but it may have been eaten, in any case, the gist of the matter was that I incorporated a preliminary base version of the xml-rpc protocol for php into my website, as soon as it is a little more well formed, I intend to add user-friendly controls for it, but I realized that what I had didn't check permissions, and I was wondering if there was an existing php package that would allow/show me how to access/set the livejournal cookie so that people would be logged in to the livejournal website as well and their username for that would be matched to the allowed usernames for a post...

Thanks.

A random thought of mine, barely related to this... Is it normal for the lj.net client to allow me to edit this post? ... the thing is [it isn't] written by me... I am tempted to add something identifying the fact that I can change it, just to see if the change will succeed

It won't. :)

Let me know what I should do here...

Nothing. :) Most clients let you see recent entries in a community, but trying to edit those that aren't your own won't get you anywhere (at point of submit). IIRC Semagic changed so that it checked ownership at point of clicking edit rather than awaiting POST to avoid scaring its users. :> It's no biggie whether the client allows you to select a post for editing if it isn't your own - you won't be able to actually edit it.

Hey, that's cool, I figured that that would probably be like that... :) Thanks for the reply ...