Hi, Baruch Even ([EMAIL PROTECTED]) wrote on 2007-03-10: > I'm not even sure that it should go for robots.txt, the idea of websec > is that it behaves more like a browser, it doesn't crawl the website, it > doesn't try to go anywhere it's not directly instructed to and if a user > insists on misbehaving the server has nothing to do for it, or do you > expect a browser to prevent a user from reloading a page every second?
I understand that websec is not a robot in the narrowest sense. Nevertheless, people (including me) seem to run it from crontab to monitor pages, and it seems that there are clueless people running it, too :( The solution that seems best to me is enabling the robots.txt mode by default and providing an option to disable it. This protects webmasters from incidents like the one that sparked this bug while still providing users who consciously WANT websec to ignore the webmaster's wishes with the choice to do so. Anyways, I don't have strong feelings either way, I just thought I'd point out the ease of implementing the change. > > The only design issue is that a robot UA requires a 'from' email address > > and I'm not quite sure how to supply that. I'd use the destination > > address(es) for the reports, but that's probably not a good idea with > > respect to privacy. What do you think? > > That won't be acceptable at all. If I will do that it will be with a > fake email address and a configuration item to change it. An upgrade to > the new version should never expose the users email to other parties. Agreed. Hey, thanks for websec, by the way - it saves me from lots of brainless reloading. ciao, -- [*Thomas Themel*] ...whatever you've done, whatever you've been, [extended contact] is all, totally, one hundred percent, your own fault. [info provided in] All. [*message header*] - Richard Ames in The Cat Who Walks Through Walls -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
