|
The WSGI support should now be much more compliant. Especially the PATH_INFO problem is fixed and there is now support for the writer returned by start_response.
This PATH_INFO support is rather nice for other REST style APIs, too: you can implement funky caching with this. If you access static content below a published tools method that doesn't exist, the method is called with the request. There you can regenerate the static content - next time you try to access the same URI, the static content is already there and will be delivered directly, without the tool needing to do any work. If the internal state that generates this static content changes, just delete the static content file - next time you access it, it will be rebuilt automatically. Cute.
WSGI directly makes use of this stuff by splitting the request path and setting SCRIPT_NAME and PATH_INFO accordingly. This should help frameworks that want to make use of PATH_INFO to produce nice looking URIs.
Another change in WSGI is the support for REMOTE_USER. The whole authentication scheme was reworked a bit - everything now uses the new $HOME/.Toolserver/etc/passwd and $HOME/.Toolserver/etc/groups based authentication (and hosts.allow/hosts.deny, of course - even RSA authentication can now be enabled for REST style access!). If the authentication recognizes a user, REMOTE_USER is set accordingly.
Another change for the authentication stuff is that now there is a usefull base class to allow easier building of tools where access is restricted to defined clients or defined groups. Of course all this can be overloaded in your tools classes to make it fit your needs.
The authentication config files (hosts.allow, hosts.deny, passwd, groups and RSA keys) are now automatically reloaded when they change. No need to restart the server just to provide new user credentials.
Due to the changes in the authentication stuff you will have to rewrite your _validate_HTTP or _validate* (REST style) handlers, as they don't get the user and password any more - instead they should check either context.client or context.groups. All password handling is now done by the framework (sure, you still could parse the auth headers from the request and do everything yourself).
Oh, and the monitor client now works again 
Update: I just commited some more changes that make pycrypto optional. Now you can decide to not install it and everything should work fine - you just don't get RSA authentication and PickleRPC. But since those are both non-standard features, you can only make use of them if you have TooFPy on both the client and the server - so if you can't rely on that, you can safely ignore pycrypto.
Additionally I made tests with more current versions:
- Python 2.3.3
- SOAPpy 0.11.6
- fpconst 0.7.0
I can report that it looks like everything works fine. I will start to do work on my OS X machine under Python 2.3 so if there are niggles left in the code, they should be found.
|
