Client reported tool (https://www.uvm.edu/htpasswd) wasn’t behaving.
Some time ago, the webteam decided to change their convention for providing friendly urls. They create a friendly alias in htdocs, and point it at a folder named website in the owners home directory. For example,
https://www.uvm.edu/~ugrsrch/ , files in /users/u/g/ugrsrch/public_html
https://www.uvm.edu/ugresearch/ , files in /users/u/g/ugrsrch/website
(Never mind that if both folders exist, these are now two distinct websites. Holy broken bookmarks and more, Batman.)
So, the password utility at
needed to be updated to recognize the existence and priority of a website folder. this was actually pretty easy. The tricky part is the construction of .htaccess . Given a REMOTE_USER of kapoodle, it is easy enough to generate this, to force SSL:
SSLRequireSSL
ErrorDocument 403 https://www.uvm.edu/~kapoodle
But now our client wants http://www.uvm.edu/MyronKapoodle. How do I infer
SSLRequireSSL
ErrorDocument 403 https://www.uvm.edu/MyronKapoodle
turns out not to be an issue: On Mar 6, 2013, at 1:42 PM, Benjamin Coddington <bcodding@uvm.edu> wrote:
Wes, I don’t think you need to worry about forcing SSL for authentication
anymore. A couple years ago we wrote an apache module that monitors all the
server’s responses looking for the WWW-Authenticate: Basic header, and if
the response would be sent un-encrypted the server instead hijacks the
response and turns it into a redirect to the same location over SSL.This nicely eliminated the possibility of sending WWW-Authenticate: Basic in
plain text, and I think it also means you don’t have to worry about
SSLRequireSSL and .htaccess-https for authentication purposes.
