[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xmlrpc-user
Subject:    RE: Does this library provide a request context?
From:       "Adam Bennett" <adamb () videx ! com>
Date:       2006-05-11 18:02:52
Message-ID: 99648C4347C8784FA390DC78478F23757ADFD2 () exeter ! videxad ! videx ! com
[Download RAW message or body]

That should do the trick, thanks a lot.  I'll give it a try with the 1.2
or 2.0 release.

P.S. I learn something new every day.  I was unaware of the ThreadLocal
class.  Cool stuff.  

> -----Original Message-----
> From: Adam Taft [mailto:adam@hydroblaster.com] 
> Sent: Wednesday, May 10, 2006 4:49 PM
> To: xmlrpc-user@ws.apache.org
> Subject: Re: Does this library provide a request context?
> 
> Adam,
> 
> I use an older version of the library (v 1.2-b1), so what I 
> do might not be the most accurate with the latest version 
> (though I assume it's practically the same).
> 
> The basic authentication credentials are available by 
> implementing the AuthenticatedXmlRpcHandler interface (or 
> ContextXmlRpcHandler) in your handler class.  So, if your 
> handler class implements this interface, the execute method 
> will be called with the client's username and password from 
> the basic authentication.
> 
>  From there, it's just a matter of looking up and validating 
> the credentials, matching it up to a user session, etc.  I 
> basically keep some User objects cached in a Map, keyed off 
> of the username and password.  Or, you could just go straight 
> to the database to lookup the user each request.
> 
> Now, the interesting thing with this approach is that your 
> public methods in your handler class are now not "exposed" to 
> the client.  When you implement one of the XmlRpcHandler 
> interfaces, the class isn't introspected for public methods.  
> What you can do though is call the Invoker class which will 
> then do the reflection just like the non-implementing "basic" 
> handler class would.
> 
> So, your calculator class might look something like this 
> (note, I didn't compile this, just typing off the top of my head):
> 
> 
> public class Calculator implements AuthenticatedXmlRpcHandler {
> 	
> 	// needed to store the current user in a thread safe way
> 	private ThreadLocal<User> userThreadLocal = new 
> ThreadLocal<User>();
> 
> 
> 	public Object execute(String method, Vector params, 
> String username, 
> String password) throws Exception {
> 
> 		// check username and password and store it
> 		User user = getUser(username, password);
> 		userThreadLocal.set(user);
> 		
> 		// use the Invoker on this class.
> 		Invoker invoker = new Invoker(this);
> 		Object obj = invoker.execute(method, params);
> 
> 		return obj;
> 	}
> 
> 	public int add(int i1, int i2) {
> 		// check the user
> 		User user = userThreadLocal.get();
> 		user.checkSomeProperty();
> 		return i1 + i2;
> 	}
> 
> 	public int subtract(int i1, int i2) {
> 		return i1 - i2;
> 	}
> }
> 
> Obviously, in the example above, you'll need a supporting 
> User class.  I 
> also end up storing the user in a ThreadLocal (as you can 
> see), so that 
> the methods (add, subtract) can get to the user object and change the 
> behavior of the method based on it.  I tried to demonstrate 
> this above.
> 
> Hope this helps.
> 
> 
> Adam Bennett wrote:
> > I've got the server and client example code working, (the 
> Calculator),
> > and I enhanced it to use HTTP basic authentication.  The 
> next thing I
> > need is for the server to know which user is making the 
> request.  For
> > example, on the server we have:
> >  
> > package videx;
> >  
> > public class Calculator
> > {
> >   public int add(int i1, int i2)
> >   {
> >     return i1 + i2;
> >   }
> >  
> >   public int subtract(int i1, int i2)
> >   {
> >     return i1 - i2;
> >   }
> > }
> >  
> > But instead lets say the result of the subtract() method 
> depends upon
> > the user who is making the call.  That is, the user 
> supplied during the
> > authentication process.  I know that if I can get the 
> HttpServletRequest
> > object then I can query it for this information, but how do 
> I get at it?
> > Is this possible with this library?
> > 
> > The real need for this steams from the fact that each user has a
> > different view of the data in our database and thus the 
> response will be
> > different for each user.
> > 
> > Thanks for your help on this.
> > - Adam
> > 
> > 
> > This message has been scanned by Symantec Mail Security for SMTP.
> > 
> 


This message has been scanned by Symantec Mail Security for SMTP.

[prev in list] [next in list] [prev in thread] [next in thread]