On Wednesday, June 09, 2010 16:41:05 Jd wrote: > Sorry.. was too distracted while writing the last post, hence lack of > clarity. > > We currently do application login using urllib2.build_opener and > CookieProcessor. Then create a custom transport (with cookies context > populated from login) and pass it while creating xmlrpc.Server (this > is what I referred to as xml-rpc handle) > From then on, all xml-rpc requests will have cookies sent, thus > identifying the "session". So here there is no need to pass the id. > > This is similar to approach/option 2. (where we do url login and then > use the context)
Actually I'd say it's option 1 - enriching header information. There could a lot to be said about this that I don't have the time right now, but a few observations, see below. First, you are non-standard here, due to already explained reasons. If you don't care about that because you in fact are the only one really working with that service, I *strongly* suggest you instead move to JSON as protocol. By doing that, you can use auth* as is, are *much* more lightweight. And most probably recycle a lot of common code between webapp and RPC-api. > I do not think we need to parse the xml-rpc request. The xml-rpc > controller will already do this. You think wrong, because the way repoze.who works is that it identifies users on the ingress, way before the request hits your controller. So if you go with the officially appraised repoze.who-way, you in fact *do* have to parse each and every XMLRCP-request, filter out the login-calls, and then perform the identification as written in the tutorials Gustavo mentioned (unless you reside to using regexp to parse the body of course.. . another can of worms....) So IMHO this is prohibitive to use the normal way of working with repoze.who because you end up eating CPU-cycles for nothing. But see below. > > Here is the xml-rpc controller method > def login(user, password): > # need some calls that would "authenticate" using repos.who > # and set session context, if the auth is correct. (similar to > login success.) > > return success or failure. For above mentioned reason, this is not the way repoze.who wants to work. You don't see a login-call inside a TG2-project because it is intercepted by the middleware. Normally that's fine, because repoze.who just has to get the POST or GET-parameters (you of course should only use POST...) of a submitted login-call. And it can easily identify the requests to intercept because of the PATH_INFO they have. So there is no easy call inside a controller to set the current identity & make sure subsequent requests get the same user. Of course you can still make it work, but that requires to exactly trace back what repoze.who does to establish the user inside a session, and set the respective headers yourself inside the controller. IMHO a short-coming and one of the reasons I created my own authentication framework, but mentioning that will most likely spawn angered responses .... > Hope this is clear and hoping to get some closure on this. > Thanks Much more so, yes. But I would not implement it that way, because it combines non-standard-conformity with either not following the book of repoze.who or parsing each and every request on ingress twice. So again my suggestion would be to - either use JSON if you can. It's *much* more lightweight, and you don't have any of these issues here. - go for the standard-conforming way of passing an exlpicit session value in every call as actual method-parameter, and simply strip that away using a decorator, which additionally sets up the identity to make predicates work (if you need that) Diez -- You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
