James' suggestion (below) is good and possibly even the "right thing" to
do. However, we're doing it a little different...
Our clients send their authentication credentials using http basic
authentication. They do this on every xmlrpc method call.
In essence, we keep a cache of usernames/passwords and associate these
to a User object. We keep track of the last activity, so we know to
send an XmlRpcException if the user has timed out (forcing them to
re-invoke a login method). We might also keep track of what IP the user
has connected from, to help avoid any hijacking problems (though that's
not needed currently for our application).
The nice advantage here, in comparison with the solution below, is that
you don't have to have every xmlrpc method accept a session id as a
parameter. Not that it is that big of a deal, but it's nice having the
underlying framework deal with it for you rather than having to provide
a method body which supports session ids.
In theory, as an additional thing you could do, you could use the
username or password field in the basic authentication as your session
identifier. It's a bit hackish, but basically the first time a client
connects, they invoke a login method like:
public String login(String username, String password) {
...
return sessionIdString;
}
Then every time after, they connect using basic authentication to send
the sessionIdString in the username field (with a blank password).
I don't see a lot of advantage of using session ids vs. providing
username/password all the time. The only advantage is if you're
concerned about someone hijacking (snooping the network line), which
would reveal the basic authentication username/password. At least with
a sessionId, the snooper only gets to hijack the session for as long as
its in place (doesn't learn the user's credentials). However, this is a
moot point if the snooper catches the login method (which would provide
the username/password anyway). The advantage of session ids is only
when the login method is done with ssl encryption and you don't want the
rest of your methods done under ssl encryption (maybe for performance
reasons).
For us, all of our methods will be invoked as ssl encrypted (since the
data payload is sensitive), so using username/password pairs or a
session id makes no difference.
Hope this helps.
James Carroll wrote:
Hi Tom,
My xmlrpc functions needed session management, and I have a login
function that returns an ID, and then each other functiton takes that ID
as the first parameter.
If they send NULL as the first parameter, then I know they're not logged
in
and there's no session information.
sess = ni.login(user, pass)
data = ni.getData(sess, type)
ni.addData(sess, newData)
...
People have hacked xml-rpc servers to use cookies for this
purpose, but the above is simple, and works with
every xmlrpc client.
-Jim
-----Original Message-----
From: Thomas Smallwood [mailto:[EMAIL PROTECTED]
Sent: Friday, September 09, 2005 1:33 PM
To: [email protected]
Subject: Session management
Does the java XmlRpcClient do session management?
If not what is a possible solution?
thanks
