[Zope] xmlrpc and sessions

[Jim Washington]

Lane Stevens wrote:

> It was my understanding that xmlrpc is stateless, and so I had 
> supposed that
> sessions being stateful would not be supported.  I had hoped that 
> there was
> a way to tie to sessions.  I assume that there would need to be a 
> transport
> mechanism of some sort to deal with sessions - but that is just a guess.
>
Yup. xmlrpc is stateless, like http is stateless.

> Related question:  Is there a best practice for dealing with state in the
> use of web services through xmlrpc?
>
> (Vague) Use case:
> I have a Zope application that carries some information from previous
> transactions in the session, and some methods that have depended upon 
> that
> information being present to produce valid results.
>
> I am creating new methods or changing existing methods and prefer writing
> tests in xmlrpc rather than as page hits - or as method calls against an
> offline instance of Zope.  In the case where these methods depend upon
> something that expects session data, I have resorted to page hits.
>
I don't know if there is a "best practice" for this.  It's possible in 
straight xmlrpc, but you probably will not like it.

If you look at the sessioning API, you'll find methods to get the 
browser id name (usually "_ZopeID" in a default session) and browser ID. 

This is the session hook, and zope looks in the REQUEST (form data and 
cookies) for e.g, {'_ZopeID': blah}, and uses the session named 'blah' 
as a dictionary for the session data as needed.

So, for pure xmlrpc, you would

1.  Make an initial request to setup the session,
2.  The session hook is added somehow to the xmlrpc payload for each 
request and response.
3.  Since xmlrpc does not have named parameters, zope probably will not 
find '_ZopeID' in the xmlrpc POST from the client, so it is up to you to 
do an extra step to unpack the xmlrpc POST into something zope sees as a 
session id.
4.  Set '_ZopeID' in REQUEST, before touching session data.  Otherwise, 
you will create a new session.
5.  Access the session data in the usual way.

So, pure xmlrpc sessions are ugly.  It probably requires rewriting each 
method (and the client) to handle this.  And this is probably not what 
you want to do.

I were doing this again (I'm remembering as I go), I would set and use a 
cookie with the session info (zope tries to acquire a cookie 
automatically as soon as you touch a session), and make the client 
return the {'_ZopeID': blah} cookie with each request.  Does your xmlrpc 
client send cookies?  This is what I would recommend.

-Jim Washington