Hi all,
I fully agree with Taras.
Question before I dig deeper:
does w3af currently identify (correctly) which parts of the URL
are the INFO_PATH (actually tartofdefence.com h/bar/123 part, see
below)?
Achim
Am 15.11.2011 14:25, schrieb Taras:
> Hi, all!
>
> Andres, when I ha
Hi, all!
Andres, when I have suggested this feature in w3af I didn't mean *full*
REST specification support.
Today a lot of web applications (especially based on frameworks like
Django or in the old way by Apache mod_rewrite module) uses REST-like
URLs e.g.:
http://example.com/foo/bar/123
Andrés,
> REST, as described in [0], has two important moving parts:
...
> 2- Heavy usage of HTTP methods like GET, POST, DELETE, PUT.
IMHO testing and/or fuzzing HTTP methods is independent of REST.
If fuzzing methods will be a feature, then there're more methods to
be tested, like:
Andres,
- Regarding the discovery method, actually a REST API es pretty unique,
maybe sending the "Accept apliccation/json" header and check for a positive
answer is a good place to start. Well coded APIs accept the OPTIONS method
to describe their behavior and their resources, vital info could be
List,
This email is just a conversation starter for defining how we're
going to deal with REST urls.
REST, as described in [0], has two important moving parts:
1- URLs that "look nice" (no parameters: /people/1/phones/23 )
2- Heavy usage of HTTP methods like GET, POST, DEL
Taras,
On Fri, Nov 11, 2011 at 1:04 PM, Taras wrote:
> Andres,
>>>
>>> I have updated base plugin and added comments and head.
>>> Is everything ok now?
>>
>> Looks good now! Are you guys going to be adding more plugins?
>
> As I think the next step in case of auth plugins is creation of simple G
Taras,
2011/11/13 Taras :
> Hi, all!
>
> Andres,
>
> Anton have made translation of our manual to Russian language.
> I read it and everything looks good. If you don't mind I'll commit it to
> the trunk/readme/RU and replace old version in it.
Please do that,
> By the way I suggest to add An
