ws-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Taft <a...@hydroblaster.com>
Subject Re: Session management
Date Fri, 09 Sep 2005 22:47:36 GMT

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:TSmallwood@webroot.com] 
> Sent: Friday, September 09, 2005 1:33 PM
> To: xmlrpc-user@ws.apache.org
> Subject: Session management
> 
> 
> Does the java XmlRpcClient do session management?
> 
> If not what is a possible solution?
> 
> thanks
> 
> 
> 

Mime
View raw message