Diez said: > > 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.
There's no officially appraised way to do it, you can do it however you want/need. You said that the only way to pass that information was in the XML-based body in the request and therefore I explained how to do it that way. But HTTP authentication is pretty common in XML-RPC too, where there's no code to write and nothing to parse. It will Just Work. > > 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 > .... That's correct, repoze.who 1 can only be used as pluggable middleware; repoze.who 2 (under development) can be used as both pluggable middleware and like a regular library in your code. But in this case I don't think it would be a problem to move that code up in repoze.who. -- Gustavo Narea <xri://=Gustavo>. | Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about | -- 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.
