I like the general idea of a dev-auth spec. Of course as you know developer mode is extremely dangerous.
I would prefer that the spec made getting into developer mode more difficult so that people who don't know what they are doing have to jump through a couple hoops before they hang themselves. Just shoving env['x-wsgiorg.developer_user'] = 'xxx' should not be enough to enable dev mode, and as I read the spec this might be enough. For example the environment value could be required to be an instance of wsgi.DeveloperUser(name) (or whatever) instead of a string so that some bit of Python at least is forced to import the right module and initialize an object before developer mode will work. This will probably be harder to do accidentally from a config file. Alternatively, the spec could say something explicit about the 'client' and the 'server' having a shared secret -- maybe by requiring the client to send a timestamp hashed using a password or something. Any level of safeguard to make it harder for the ignorant innocent bystander sysadmin to shoot himself in the foot might be nice. I'm particularly concerned because as it stands the spec might allow a WHIFF "remote procedure call" to get itself into developer mode automatically, with no password required, unless I add something explicit to prevent it. Just my 2p. -- Aaron Watters === http://aaron.oirt.rutgers.edu/myapp/docs/W1200_1400.stdMiddleware _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com