Is there any way to establish/maintain session data between xmlrpc calls? Thanks, Lane. -- Lane Stevens Terrapin Technologies, Inc. http://www.cycletime.com
Lane Stevens wrote:
Is there any way to establish/maintain session data between xmlrpc calls?
I am pretty sure it works just the same way as for anything HTTP. Do you have a use case where sessioning is not working? I am doing something similar in xmlrpc, but my use case has cookies and auth headers, so I have something more user-centered than session-centered. -Jim Washington
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. 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. Thanks, Lane. On Thu, Aug 19, 2004 at 08:32:50AM -0400, Jim Washington wrote:
Lane Stevens wrote:
Is there any way to establish/maintain session data between xmlrpc calls?
I am pretty sure it works just the same way as for anything HTTP. Do you have a use case where sessioning is not working?
I am doing something similar in xmlrpc, but my use case has cookies and auth headers, so I have something more user-centered than session-centered.
-Jim Washington
-- Lane Stevens Terrapin Technologies, Inc. http://www.cycletime.com
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
Lane Stevens wrote at 2004-8-19 09:40 -0600:
... Related question: Is there a best practice for dealing with state in the use of web services through xmlrpc?
I would use explicite state ids, similar to: state_id = open(...) # create session via XML-RPC ... call(state_id, ...) ... -- Dieter
Lane Stevens wrote at 2004-8-18 11:59 -0600:
Is there any way to establish/maintain session data between xmlrpc calls?
Not so easy. Sessions are identified by a session id, generated by the "browser_id_manager". The "browser_id_manager" currently is ready to look for the session id in "cookies", "request arguments" or the URL. Almost surely, your XML-RPC transport ignores cookies (if not, you have won). I do not know a way to provide request arguments for an XML-RPC call other than what should become the method arguments. Remains the use of the URL to transport the session id. You probably will need an special method that creates a session and returns the session id. You then can call further sessions with this session id in their URLs. -- Dieter
participants (3)
-
Dieter Maurer -
Jim Washington -
Lane Stevens