* 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.
