Hello Patrick, On Tue, Aug 4, 2009 at 10:53 AM, Patrick Hof<patrick...@web.de> wrote:
>> I think option number 2 is the way to go if we want to get around that. My >> guess though, is that anyone who wants to issue requests to the passive >> discovery plugins will be able to define their whitelist/blacklist on the >> webspider plugin and allow the other plugins to function correctly. Again, I >> think that should be added to the documentation as a side effect of the >> global >> whitelist/blacklist. > > Hm, ok, that's a point. I guess we can assume that people know what they're > doing when they enable the plugins. I'll have to look into the webSpider code > when I have the time, but would it make sense then to remove the black- and > whitelisting from it and just use the global black- and whitelisting? Assuming > of course that the patch makes it into trunk :). I think you do want to keep the whitelist/blacklist options in the web spider plugin as that is the most likely place someone will want to restrict scanning. The global option would be for anyone with a need to make sure none of their requests go outside of the scope of the test, or wanting to make sure w3af doesn't discover large media files using other plugins and suck those down. I would think the whitelist/blacklist in the web spider plugin will see substantially more use and having it in both places increases the flexibility of w3af. And yes, assuming it makes it into trunk =) Zach ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ W3af-develop mailing list W3af-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/w3af-develop
