Create a new account
First, make sure the var cookiesecure is set to 1, and allow_nonadmin_ssl is set how you want it (I recommend keeping it off, as a bunch of regular users could really swamp an SSL server's CPU).
If you may be adminning the site over a network that you believe to be secure from sniffing, set the regex var admin_secure_ip_regex to something appropriate. These are the IP numbers that the code considers accesses from to be secure whether they arrive over SSL or not.
For your first try, set to 0 the vars admin_check_clearpass and admin_clearpass_disable. We'll set them to 1 later.
Enable SSL access to your site by compiling mod_ssl into your Apache. The way I included my SSL conf file was to append this to my httpd.conf, right after the Include that pulls in slash.conf:
That file is mainly created by mod_ssl as I recall, but in its VirtualHost section you'll have to make it look like a normal Slash VirtualHost. Note that there is only one SSL website allowed per IP number! Anyway, my test site's VirtualHost portion of httpd_ssl.conf looks like:
#### SSL Virtual Host Context## <VirtualHost _default_:443> # General setup for the virtual hostDocumentRoot "/usr/local/slash/site/daisy.jamienet/htdocs"Ser verName daisy.jamienetServerAdmin firstname.lastname@example.orgErrorLog logs/daisy.jamienet-ssl_error_logTransferLog logs/daisy.jamienet-ssl_access_log PerlSetupEnv On PerlSetEnv TZ GMT SlashVirtualUser slash SlashCompileTemplates Off PerlAccessHandler Slash::Apache::Banlist PerlAccessHandler Slash::Apache::User PerlCleanupHandler Slash::Apache::Log PerlCleanupHandler Slash::Apache::Log::UserLog PerlTransHandler Slash::Apache::IndexHandler PerlTransHandler Slash::Apache::User::userdir_handler [...AddTypes, AddHandlers...] # My additions ServerAlias daisy.jamienet ServerPath /daisy.jamienet ErrorDocument 403 /404.pl ErrorDocument 404 /404.pl
The last step, after restarting the server, is to go to https://yoursite.name/users.pl . If you go straight to the homepage, you'll probably be bounced to the non-secure side (since you left allow_nonadmin_ssl turned off, and the site doesn't know you're an admin because you haven't logged in on the secure side!). /users.pl is the one URL that you can visit on the secure side without having logged in, for obvious reasons. Log in, and you should receive a secure-side cookie and be redirected to the secure-side homepage. Hooray.
At that point, you'll want to go back to the nonsecure side and log out. Your browser should keep your secure-side cookie separate, so you will be anonymous to your site on the non-secure side, and an admin on the secure side.
If you want to be sure your admins' passwords are not being sniffed, set the var admin_check_clearpass to 1. This will make sure that if their clients ever send their passwords in the clear, on the non-secure side, they see a warning message on every page, and you'll get a warning in your daily site email. Only after they log out on the non-secure side, and change their password securely, will the warnings go away.
If you want to be really strict, set admin_clearpass_disable to 1. In the event that an admin's password is ever sent in the clear, this disables their admin powers, until their password is changed securely. Some admins may object to being exposed to kryptonite like this, so set it with caution, only after your admins have gotten used to the new regime :)
Am I naked in the rain running the 2.2.6 tarball? And how safe is the upgrade path?
Get More Comments