Terrific.. many thanks! Curious if/when the patch will make it's way into the main branch?
-G > Geoff, > > Fixed #134! Please note that this fix is only in threading2 branch. > > Regards, > > On Sat, Feb 16, 2013 at 1:45 PM, Andres Riancho > <andres.rian...@gmail.com> wrote: >> Reproduced it in my environment too, created a bug in our github repo >> [0]. I'll try to fix it today. >> >> [0] https://github.com/andresriancho/w3af/issues/134 >> >> On Fri, Feb 15, 2013 at 5:12 PM, Geoff Galitz <ge...@galitz.org> wrote: >>> >>>> Geoff, >>>> >>>> On Fri, Feb 15, 2013 at 7:51 AM, Geoff Galitz <ge...@galitz.org> >>>> wrote: >>>>> >>>>> >>>>> Hi. >>>>> >>>>> I've got a basic usage question. If I point w3af at a target using a >>>>> given >>>>> profile (e.g. full_audit) I get quite different behavior and results >>>>> depending on if I specify the port or not. >>>>> >>>>> If I specify the port (http://192.168.2.5:80, for example) I get a >>>>> pretty >>>>> short and not particularly useful output. If I leave the port off, I >>>>> get >>>>> a ton more data and is much more what I expect including traversing >>>>> subdirectories which does not happen if I specify the port. >>>>> >>>>> Is this behavior by design? It affects scripting and wrapping from >>>>> some >>>>> other tools I use. >>>> >>>> This is not by design, it should be a bug. Which version are you >>>> using? If it's not threading2, could you test it there using the >>>> console UI? (GUI is broken in threading2 at the moment). These steps >>>> might be useful for you to debug: >>>> >>>> git clone git://github.com/andresriancho/w3af.git >>>> cd w3af >>>> git checkout -b theading2 >>>> >>>> ./w3af_console -p full_audit >>>> target set target http://192.168.2.5:80/ >>>> start >>>> exit >>>> >>>> ./w3af_console -p full_audit >>>> target set target http://192.168.2.5/ >>>> start >>>> exit >>>> >>>> I remember a similar problem being reported a while ago, I think I >>>> fixed it in threading2, but it's never bad to double check. >>>> >>> >>> >>> Hi. >>> >>> I just tried it again using the procedure you outline above and also >>> the >>> packages in both Debian and Backtrack 5r3. In each case I get the same >>> behavior (the aforementioned bug). >>> >>> In Backtrack the version is 1.2 r6654. In Debian the version is >>> 1.0-rc3svn3489-1. >>> >>> -G >>> >>> >>> >>> >>> >>> >>> ------------------------------ >>> Geoff Galitz >>> http://www.galitz.org >>> >> >> >> >> -- >> Andrés Riancho >> Project Leader at w3af - http://w3af.org/ >> Web Application Attack and Audit Framework >> Twitter: @w3af >> GPG: 0x93C344F3 > > > > -- > Andrés Riancho > Project Leader at w3af - http://w3af.org/ > Web Application Attack and Audit Framework > Twitter: @w3af > GPG: 0x93C344F3 > > ------------------------------ Geoff Galitz http://www.galitz.org ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ W3af-users mailing list W3af-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/w3af-users
