Run ./go. Exit from your browser on the client machine and reload it to make sure it does password checking properly (you will probably need to do this every time you make a change throughout this exercise). If you access the salespeople's site again with the user ID guest, anonymous, or air-head, and any password you like (fff or 23 or rubbish), you will get access. It seems rather silly, but you must give a password of some sort.
This time you can leave both the ID and password fields empty. If you enter a valid username (bill, ben, sonia, or gloria), you must follow through with a valid password.
Anonymous_NoUserID off Anonymous_VerifyEmail on Anonymous_LogEmail on
The effect here is that the user ID has to look something like an email address, with (according to the documentation) at least one "@" and one ".". However, we found that one "." or one "@" would do. Email is logged in the error log, not the access log as you might expect.
Anonymous_VerifyEmail off Anonymous_LogEmail off Anonymous_Authoritative on
The effect here is that if an access attempt fails, it is not now passed on to the other methods. Up to now we have always been able to enter as bill, password theft, but no more. Change the Anonymous section to look like this:
Anonymous_Authoritative off Anonymous_MustGiveEmail on
Anonymous guest anonymous air-head Anonymous_NoUserID off Anonymous_VerifyEmail off Anonymous_Authoritative off Anonymous_LogEmail on Anonymous_MustGiveEmail on
The documentation says that Anonymous_MustGiveEmail forces the user to give some sort of password. In fact, it seems to have the same effect as VerifyEmail: A "." or "@" will do.
<Directory /usr/www/site.anon/htdocs/salesmen> </Directory>
Copyright © 2001 O'Reilly & Associates. All rights reserved.