I have a method which gets called for every request, that checks if the request came in thru a "valid" port; port 443 is in the list of "valid" ports. This I "know" since, in our setup, we use Apache SSL on port 443. It is also pos- sible to use several ports that are known to use SSL, so it is quite flexible.
I forgot to mention that user-credentials passing part. After we have established an SSL-connection, we use a forms based login procedure, that sends, in cleartext but over an encrypted ssl-connection, the username and password. We also make sure that the login form can only be used over SSL. On the server side, we authenticate and make some user-group checks; when we have indentified the user, we generate a random cookie that we send back to the client. The expiry date on the cooke is not set, if IIRC, or it is set to some date in the past, to ensure that the well-behaved browser does not store it to disk, but keeps it in RAM. We also have a time-out on the sessions, so if someone goes away from their computer while logged in, their session expires after a specific amount of time. This won't let us achieve 100% security, but at least the user won't stay logged on forever, and we minimize the time frame on which a security breach can happen. On the server side, we store the value of the cookie, along with the username and the expiry date of the session (the cookie's value is the actual session id). On every request, we ask the client for our cookie, and then we look it up on the server, check the expiry date and if it is still valid, then we know the username of who made the request and can consider him/her to be authenticated. We update the expiry date of the session and e wait for the next request. This way we send transfer our credentials once and only once over an encrypted channel, and then we just retrieve the cookie. If you want more security it is of course possible to set a new random cookie with every request, so that the cookie is only valid for a single request, thus ensuring that the cookie can't ever be re-used. We also have a logout procedure that resets the cookie on the client to a non-sense value, and we then delete the session info on the server. This is also what happens when the session times out. The reason we use a formsbased login is precisely to avoid having users credentials passed along with every request. Digest authentication is available, but not all browsers support it. We are deploying DCE/DFS on campus now, and ideally we'd like to have a DCE enabled browser; if we did, we could perhaps adapt Zope to use DCE credentials... but i'll guess we'll have to wait a bit longer for that. BTW - has anyone used Zope alogn with Kerberos authentication? /dario