XMLRPC Ruby 1.8.6 stdlib Authentication/docs

Ruby
1

Greeting All,

I am writing a Rails App which includes (I hope) an XMLRPC API
interface. I am working with the XMLRPC library in Ruby 1.8.6 to write
a client and a Mock of the Rails server. In looking at the code in the
Lib I have a few questions.

First, the documentation is sketchy in the client and server classes and
non-existent in the the supporting files. I’ve made notes in my local
copy and would be happy to share them, if they would be appreciated.
There seems to be a lot of hidden functionality that is not documented.

Next, I need to authenticate the user, and there seem to be a number of
different ways to do this: HTTP Authentication, Cookies, or within the
RPC it’s self. This last is the one used in the two examples that come
with Rails, but I consider it suboptimal. What is required for the
other two? I read this: Xmlrpc authentication - Rails - Ruby-Forum
but I’m not clear on how the user information makes it from the caller
to my RPC function.

With stand alone XMLRPC server, is it possible to see the original HTTP
request object from within the handler block?

Finally, in client.rb lines 565 and 566 appear to handle cookies in a
very non-standard way:

c = resp[“Set-Cookie”]
@cookie = c if c

It looks to me like having the server set a new cookie simply replaces
all the existing cookies. My initial guess is that this was a hack to
make secessions work under Rails without having to completely support
cookies. Can anyone shed some light here?

Thanks for the help.

J. F. Miller

2

John M. wrote:

There seems to be a lot of hidden functionality that is not documented.
Has your reading included http://www.ntecs.de/projects/xmlrpc4r/ ? If
so, please share your thoughts. I can’t remember if it’s signposted
from the sources or not.

3

Alex Y. wrote:

John M. wrote:

There seems to be a lot of hidden functionality that is not documented.
Has your reading included http://www.ntecs.de/projects/xmlrpc4r/ ? If
so, please share your thoughts. I can’t remember if it’s signposted
from the sources or not.

Yes I have. It appears that it is almost identical to the documentation
in the RDOC. However, as I mentioned above, I am trying to create a
system for debugging my Rails app, and I would therefore like a little
more control then the default client gives. In file like create.rb,
parse.rb, and utils.rb, nothing significant is documented. I have
worked out most of what it does and written it into my copy of the code.
My offer is to share this as a start for documenting the rest of this
library if that would be a useful thing.

There is very little documentation on the Marshallable module, and
though I am not using it, I can see how it would be an excellent thing
to know more about.

I mentioned the issue with cookies before, but as it stands it would at
least be nice to know that this mechanism does not provide the standard
client behavior with cookies.

While one is able to set different parsers and writers, it is not clear
either what the differences between them are, nor how one might go about
roiling ones own. This is ultimately what I have done so that I can
watch what the client and server are actually saying to each other. At
minimum the Abstract classes could provide some documentation on the
expectations of there functions, and the concrete implementations
shipped could provide some explanation of the trade-offs made by each.

Again, I understand that this is a bit of a back-woods library, and I am
not demanding that anyone write this documentation instead of writing
code. It is only that I have spent enough time with this library that I
might be able to make a start at it, and wonder if it would be
appreciated if I did.

Thank you for taking the time to reply.

John M.

4

John M. wrote:

more control then the default client gives. In file like create.rb,
parse.rb, and utils.rb, nothing significant is documented. I have
worked out most of what it does and written it into my copy of the code.
My offer is to share this as a start for documenting the rest of this
library if that would be a useful thing.
Personally, I think it would. More (good) documentation is always a
good thing.

I mentioned the issue with cookies before, but as it stands it would at
least be nice to know that this mechanism does not provide the standard
client behavior with cookies.
While I’ve done a fair amount of work with the XMLRPC library, I’ve not
actually had to use the cookie functionality yet. I’m sure this would
have bitten me in the future if you hadn’t brought it up.

While one is able to set different parsers and writers, it is not clear
either what the differences between them are, nor how one might go about
roiling ones own. This is ultimately what I have done so that I can
watch what the client and server are actually saying to each other.
I’ve been intrigued by this in the past, but I haven’t had the time (or
enough of a reason) to investigate. Specifically I was wondering if
there might be any performance differences between the included parsers,
and whether it would be worthwhile implementing a libxml-based one.

Again, I understand that this is a bit of a back-woods library, and I am
not demanding that anyone write this documentation instead of writing
code. It is only that I have spent enough time with this library that I
might be able to make a start at it, and wonder if it would be
appreciated if I did.
Certainly by me. It would probably be worth posting documentation
patches to ruby-core to see what the maintainers think.

5

Follow Up Inline
Greetings again,

I’m posting this here as a follow up with what I’ve learned. Too many
threads on this list never get resolved and the original poster never
come back with the results. Below is as much as I’ve been able to
gather on the answers to my questions.

I am writing a Rails App which includes (I hope) an XMLRPC API
interface. I am working with the XMLRPC library in Ruby 1.8.6 to write
a client and a Mock of the Rails server. In looking at the code in the
Lib I have a few questions.

While I’ve seen nothing official it is rumored
(AWS Client - There has to be a better way - Rails - Ruby-Forum) that AWS is leaving rails
so I’m thinking that I can use the stdlib to role moy own with more
flexibility.

First, the documentation is sketchy in the client and server classes and
non-existent in the the supporting files. I’ve made notes in my local
copy and would be happy to share them, if they would be appreciated.
There seems to be a lot of hidden functionality that is not documented.

Thanks for the feedback. I will clean this up a bit ans submit a patch
to Ruby-doc.

Next, I need to authenticate the user, and there seem to be a number of
different ways to do this: HTTP Authentication, Cookies, or within the
RPC it’s self. This last is the one used in the two examples that come
with Rails, but I consider it suboptimal. What is required for the
other two? I read this: Xmlrpc authentication - Rails - Ruby-Forum
but I’m not clear on how the user information makes it from the caller
to my RPC function.

I’ve looked onto this and I think that I am happier sending Username and
Session ID as part of the the request body. Current implementation not
withstanding, there is nothing in the XMLRPC standard the requires that
HTTP be used as the communications channel. Even if that is the channel
of communication, there is no requirement that the client or server
handle specifics. Both HTTP Authentication and Cookies are optional
parts of the HTTP standard, (as is seen with my cookie question below.)

With stand alone XMLRPC server, is it possible to see the original HTTP
request object from within the handler block?

Short answer is no. The long answer is that the handler should not
anticipate having any HTTP Request as that is not required. On the
other hand the code that extracts the XML data out of the post does have
access to this data. Ideally all information should be in the body of
the message, but it is possible to modify the message with things like
authentication information before passing it on to the handler code.

Finally, in client.rb lines 565 and 566 appear to handle cookies in a
very non-standard way:

c = resp[“Set-Cookie”]
@cookie = c if c

It looks to me like having the server set a new cookie simply replaces
all the existing cookies. My initial guess is that this was a hack to
make secessions work under Rails without having to completely support
cookies. Can anyone shed some light here?

I will be sure to note this in the documentation I submit, If time
allows I think I also might try my hand at patching it to conform closer
to the HTTP standards.

Thanks for the help.

J. F. Miller