Jamie Heilman wrote:
Granted. I indeed want prevent users from coming in the wrong door. And it would really help if there wasn't a wrong door at all - therefore my question ;).Well its true you can't prevent users from compromising their credentials, but you can prevent users from coming in the wrong door, as it were. I'm not clear on which one you really hope to accomplish, though from your proposed modifications it looks like the latter. Preventing users from compromising their creds can only be effectively done through education. For example, even if you used client certificates (which, afaik, are only used once an encrypted channel has been established) instead of basic auth there's nothing to stop a user from giving their cert and any requisite ancillary usage information (like the passphrase to decrypt it) to somebody else.
The only ideas I have to tackle this without modifying zope itself are
- customize all pages which need authentication to check for "https://" in one of the relevant REQUEST attributes and do a redirect if not.
- use apache with some magic to trigger redirection if it encounters authentication headers in the request.
- use apache with some rewrite magic trigger redirection when a substring like "manage" is found in the request.
These alternatives are neither elegant, nor really secure.
I would agree the first two aren't sane, the third however is as good
and as secure as you're going to get. Techniques for accomplishing it
have been discussed on the zope list before and are undoubtedly in the
The third alternative is indeed secure compared to the other two, in that it prevents plaintext credentials from going over the wire - as long as you remember to use always names like manage*. It's factually more insecure than my idea in that even ZMI's methods can be accessed with mangled names (e.g. http://server/manage/index_html). It's cumbersome because newly installed products always have to be checked for the method names.The mods you've posted with respect to guarding the WWW-Authenticate header aren't likely to work, and certainly wouldn't be flexible enough to allow, for example, mandating SSL usage for all /manage* requests while allowing clear-text basic auth for other restricted areas. Apache rewrite rules OTOH are flexible enough to allow this. I'm unclear as to why you consider it to be insecure, care to elaborate?
It's shaky, because if your filtering is too broad, better don't give the "corporate management profile" page an intuive id ;). And it's clearly worse performance wise for the typical use case, because you now get a load of rewrite stuff for any URI which has to be processed.
All these complications and administrative burdens alone lead in effect to insecurity.
The example code I posted was more or less to illustrate my intention, if I'd know where to implement such a hook, I'd probably try to make it more flexible. Make it dependend from a startup flag, and check for a magic attribute in the acquisition chain perhaps, which prevents the redirect. Also allow for redirects to a different host.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - http://lists.zope.org/mailman/listinfo/zope-announce