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)
I do not think we need to parse the xml-rpc request. The xml-rpc
controller will already do this.
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.
def foo(x, y):
calls... foo_common
def foo_common(x, y) (somewhere else.. common to bothe http and
xml-rpc
....
# use session['user'] and other application specific context in
session.
....
My gut is that this code should be similar to code that TG2 must be
calling while setting up the request ingress.
Hope this is clear and hoping to get some closure on this.
Thanks
/Jd
On Jun 9, 12:15 am, "Diez B. Roggisch" <[email protected]> wrote:
> > * We have
> > * a URL based login method (which sets up the cookies)
> > * and we attache the cookies to the xml-rpc handle.
>
> What is an XMLRPC-handle?
>
> > This is similar to option to suggested by Diez. The problem with this
> > is that we need to implement login in each language for this to work.
> > (among feeling it to be a hack)
>
> Which option?
>
>
>
> > I was/am still hoping.. :)
> > a. XML-RPC controller to "parse" the user id..etc.
> > b. We calling some repos.who) to create/populate session.
> > (for us @ decorators are not very high priority.. I will have to
> > double check though)
>
> > From the discussion.. I still have some questions..
> > a. how does repos.who auth extensions/plugin suggested by Gustavo
> > go ? i.e how does it tie in to TG2)
>
> Well, as eager as Gustavo always is to point out the power of
> repoze.wh*, he has so far shown little if any understanding of the
> problem at hand. His suggestions don't solve anything so far.
>
> The options that exist I've already outlined. If you insist on using
> repoze.wh* on request ingress, I *strongly* suggest using the session-
> key-as-part-of-the-connection-URI-approach.
>
> There are two reasons for this:
>
> - it fits the repoze.wh* model of identifying authentication
> information solely on the headers/keys in the WSGI-environ.
> - not having to inspect the wsgi.input body saves you a *lot* of
> computation time. You really only want to parse the XMLRPC-call once.
> Believe me, we had a XMLRPC-based system with several tiers running -
> and found out that it consumed 70% of it's time parsing and producing
> XML....
>
> If you find the specific URL-approach hackish, IMHO your best bet is
> the decorator variant, stripping off the first session parameter. The
> identity that is then needed for repoze-predicates to work with is
> stuffed into the environ under the key
>
> 'repoze.what.credentials'
>
> I'm not aware of something that easily sets up thes identity through
> one call inside a controller (or decorator in this case), so you need
> to cobble that together.
>
> Then a passed predicate can run with that enriched environ.
>
> ATTENTION: this approach of course *requires* you to decorate all
> protected actions! A controller-level predicate (allow_only) won't work!
>
> For that, you sure need to set up the credentials in the repoze.who
> middleware. Which IMHO only leaves the URI-based approach. But if you
> are willing to deal with the cost of parsing each request twice, you
> can of course also work with a repoze.who plugin that xmlrpclib.loads
> the wsgi.input, identifies the user, and possibly even strips out the
> first parameter - although I'd be cautious about that because I
> frankly have no idea of the order of things happening inside
> repoze.who, and you might end up modifying the request to early for
> other parts that still rely on the session parameter.
>
> > b. Would returning credentials suggested last would ....session etc.
> > correctly ?
>
> No. As I've already pointed out & so far blissfully ignored by
> Gustavo: that only authenticates your login-call. Nothing else.
>
> 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.
