I didn't test the code, but i think it'll work. If you're new to
repoze.who, you may find this interesting, although it also covers
repoze.what: http://gustavonarea.net/blog/posts/repoze-auth/
I'm sorry, but this won't work. The fault here is certainly not on
repoze.wh* side, but what you presented so far is just working to
authenticate the login call itself. But obviously the OP wants a bunch
of authenticated (and possibly authorized) API-calls, not just one.
So there are basically three ways of doing this, each of them means
you got to die one particular death:
1) use HTTP-header-information to identify authenticated requests.
That means that in whatever I* of repoze.wh* you need to set a cookie
(as with some other authentications), and make sure that cookie is
transferred by the client each and every time. Then some other I* of
repoze.wh* needs to identify the current user based on that cookie.
Cookie could be any kind of header information of course.
This has the major problem of not being part of XMLRPC standard. So
you can't for example use the simple xmlrpclib-client of Python.
Instead, you'd have to provide your own implementation, based on e.g.
urllib2 or mechanize + using dump/load from xmlrpclib. And this is
only for Python - if you want any other language, you must investigate
if and how easy it is to comply with this. It might be a PITA.
2) use a URI-based session identification. This works nicely with
repoze.wh*. What you do is that on login, you return an *URI* that
points to an authenticated version of your service. So let's say your
service is available at
http://myhost/service
Then on successful login, you return something like
http://myhost/service/<sessionid>
The client has to re-connect to this URI. Then some I*-part of
repoze.wh* will be able to identify this as part of the PATH_INFO in
environ, and strip it of whilst additionally preparing the
authenticated identity.
The obious disadvantage of this approach is the rather hackish re-
connection thing, especially nasty if you happen to expose the service
under various DNS-names. But otherwise, it's the easiest.
3) the pure XMLRPC-way is to have login() return a session-id (numeric
or string-based doesn't matter, although for security reasons, it
probably should be a hash) which then on *EACH AND EVERY XMLRPC
METHOD* is the first parameter. Like this:
login(user:str, password:str) -> str
delete_all_my_data(session:str) -> bool
Then there are essentially two ways to deal with this:
- using repoze.wh*, you need to fully read, parse & understand the
XMLRPC-request, extract the first parameter, establish the identity
information (or render an XMLRPC-fault if un-authorized), and pass the
payload down again.
- instead, bypass repoze.what alltogether. Fully. Instead, use a
custom decorator, like
@xrequired()
def my_action(self, parameter):
....
@xrequired(predicate)
def my_other_action(self, parameter):
...
which will
- take the first parameter to my_action, use it as session, look
that session up, if proper, install the identity somehow so that
predicates work (if you really need them), and possibly even strip it
from the delegating call to my_action so that in your app-code you
don't have to bother.
I'd personally go for the last option. It's the most standard-conform,
and easy to implement. And the additional burden on the client can be
abstracted away easily.
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.
