2009/1/21 Andres Riancho <andres.rian...@gmail.com>:
> Sasha,
>
> On Wed, Jan 21, 2009 at 9:30 AM, Alexander Berezhnoy
> <alexander.berezh...@gmail.com> wrote:
>> Andres,
>>
>> 2009/1/21 Andres Riancho <andres.rian...@gmail.com>:
>>> Sasha,
>>>
>>> On Wed, Jan 21, 2009 at 6:41 AM, Alexander Berezhnoy
>>> <alexander.berezh...@gmail.com> wrote:
>>>> Hi Andres!
>>>>
>>>> 2009/1/21 Andres Riancho <andres.rian...@gmail.com>:
>>>>> List,
>>>>>
>>>>>    I've created a task in the TODO list for v1.0 some time ago, that
>>>>> basically says [0]:
>>>>>
>>>>> """I should separate discovery plugins into two different types:
>>>>>
>>>>> - The ones that find new URLs
>>>>> - The ones that find things about the site"""
>>>>>
>>>>>    A clear example of a plugin that finds new URLs is the webSpider,
>>>>> and a clear example of a plugin that "finds things about the site" is
>>>>> the hmap plugin, which fingerprints the remote webserver. I've been
>>>>> thinking, and I'm pretty sure that w3af is going to have a plugin
>>>>> family called "crawl" for the plugins that "look like webSpider",
>>>>> but... I'm not sure how to call the other plugin family. Anybody has
>>>>> ideas? Please share =)
>>>>
>>>> Would not be reasonable then, to join the "grep" plugins with the
>>>> second new type ("The ones that find things about the site")
>>>
>>> No, because grep is passive and this new type is completely active.
>>> They do the work in different ways.
>>>
>>>> I'm agree with Steve that finding URL's and crawling them could be an
>>>> other task for the split.
>>>
>>> What about what I said about plugins that are run more than once, with
>>> different input, and always return the same result?
>>
>> Ok, let's consider all the properties a plugin can have, like
>>
>> - Active/passive
>> - Audit phase
>> - Run once / Run always
>> - Intention:
>>  - find something in existing data
>>  - initiate new requests
>>  - generate probes
>> - What parts of kernel and kb are used?
>>
>> etc...
>>
>> Then we could try to find a suitable classification.
>> As for me, I'm happy with the existing one. What is the purpose of the
>> new classification:
>> 1) Make usage more easy and intuitive
>> 2) Make development more convenient
>> 3) Any long-term plans for refactoring?
>
> 1) I think that users will appreciate this change, because all the
> "information gathering" will be in one part, and the "crawlers" will
> be in the other section.
>
> 2) One of the things that I want to avoid is this section of code:
>
>        if not self._run:
>            # This will remove the plugin from the discovery plugins
> to be runned.
>            raise w3afRunOnce()
>        else:
>            # I will only run this one time. All calls to MSNSpider
> return the same url's
>            self._run = False

I'd solve this by adding a standard method like "runOnce" or "preRun"
into plugins which, when defined, is called by the core.
Then a developer would implement the appropriate method without having
to validate the state.

Sasha.

///////

>
> That's repeated in all the discovery plugins that "are run once".
>
> 3) Maybe I should move this change to 1.10 release. I don't know if a
> big change like this one ok to do one week before a release :S :S
>
>> Sasha.
>>
>> ///////
>>
>>>
>>>> I think, we need to publish a complete plugin list and discuss their
>>>> classification. Probably, the same plugin could be dedicated to the
>>>> several groups.
>>>
>>> I disagree with the fact of having a plugin in more than one category.
>>> It would be a mess for the final user, and a mess in the core
>>> implementation.
>>>
>>>> Sasha.
>>>>
>>>> ///////
>>>>
>>>>>
>>>>> [0] 
>>>>> https://sourceforge.net/pm/task.php?func=detailtask&project_task_id=147178&group_id=170274&group_project_id=48542
>>>>>
>>>>> Cheers,
>>>>> --
>>>>> Andres Riancho
>>>>> http://w3af.sourceforge.net/
>>>>> Web Application Attack and Audit Framework
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> This SF.net email is sponsored by:
>>>>> SourcForge Community
>>>>> SourceForge wants to tell your story.
>>>>> http://p.sf.net/sfu/sf-spreadtheword
>>>>> _______________________________________________
>>>>> W3af-develop mailing list
>>>>> W3af-develop@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/w3af-develop
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Alexander (Sasha) Berezhnoy
>>>> http://sandals-on-my-head.blogspot.com
>>>>
>>>
>>>
>>>
>>> --
>>> Andres Riancho
>>> http://w3af.sourceforge.net/
>>> Web Application Attack and Audit Framework
>>>
>>
>>
>>
>> --
>> Alexander (Sasha) Berezhnoy
>> http://sandals-on-my-head.blogspot.com
>>
>
>
>
> --
> Andres Riancho
> http://w3af.sourceforge.net/
> Web Application Attack and Audit Framework
>



-- 
Alexander (Sasha) Berezhnoy
http://sandals-on-my-head.blogspot.com

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
W3af-develop mailing list
W3af-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/w3af-develop

Reply via email to