Revisiting break buttons / functionality

[psiinon]

Just raised an issue for this (http://code.google.com/p/zaproxy/issues/detail?id=739) but thought it would be easier to discuss here.

I've had various feedback which shows people are still having significant problems with the break buttons.

Therefore I think we should revisit them asap, hence this thread ;)

I dont really want to make any suggestions yet, other than say that we can change then in _any_ way we want.
The priority has to be usability and making them intuitive.

So ... suggestions please!

Simon

[r.f...@adinstruments.com]

Need to be more usable , How about ...


Move the buttons to the header bar of the Request and Response 'panels' - maybe left aligned , before the Header / Body format selectors

The buttons need to ( like we already have ):

1. Attention = indicator that the panel has a caught a request / response and needs attention
2. Enable = on / of for catching either next request or response - if enabled then allow editing of the content in request / response panels when caught.
3. Send-Break Point = send content to browser or server and process until next Break Point, if any
4. Send-Next = send content to browser or server and process next request or response depending on Enable setting ( maybe you only want all responses )
5. Drop = drop message



Can do away with the break panel ?

For the Break Points

Rather then a single 'enabled' can we allow setting of break on the Request or Response or Both

[psiinon]

Go to Options / Display and unset "Show main toolbar" and then restart ZAP.
You will now no longer have a main / top level toolbar and the Break controls will have moved to the Break tab.
That similar to what you are suggesting?

In theory we _could_ do away with the Break panel, but in practice that could involve quite a bit of work :/
What does everyone think? Would it make things much easier?

Re setting break points on Request and/or Response - good suggestion!
I've raised it as: https://code.google.com/p/zaproxy/issues/detail?id=1276
I've also flagged it as an IdealFirstBug - anyone fancy having a go at it?

Cheers,

Simon

[Dave Hutira]

Hi Simon,

I'm new to OWASP and ZAProxy, but do have Java experience, and would like to learn more and help out. I've been looking at
starting with https://code.google.com/p/zaproxy/issues/detail?id=1276, so I'm learning more about how breakpoints work
in ZAProxy. They seem to work well from what I can tell, but I think maybe I'm not seeing the big picture. A few observations:

     I assume the request/response change applies to the 'All' breakpoint functionality, since there's already an option in the
     'Custom' breakpoint for request/response headers and bodies.

     I see 'Toggle break on all requests/responses' choices in the Tools menu, but I can't seem to get them to do anything.

So, I'm assuming that for issue 1276, I'd add separate request and response buttons in the toolbar after the existing 'All' button, implement the
processing, and hook up the 'Toggle break' menu choices the same as the buttons. Please let me know if I'm misunderstanding things; any additional
explanation is appreciated...

Dave

[psiinon]

Hi Dave,

Welcome aboard :)

This bug refers to the fact that when you add HTTP break points they apply to both requests and responses - you cant select just one.
Click on the 'Add a custom HTTP break point...' button (or type Control-A) and you'll get this dialog:


So we'd like to be able to specify if this break point applies to requests, responses or both.
It would be good to have it similar to the Web Sockets break point dialog:

ie with 'Direction' label and then checkboxes for: Request and Response.

Hopefully that shouldnt be too hard - let us know if you have any other questions about it.

Many thanks,

Simon


 

[Dave Hutira]

Hi Simon,

Thanks for the quick response....I'm glad to be aboard, Captain ;)

I'll look at the WebSocket processing, and use it as an example...

Dave

[Dave Hutira]

Hi Simon,

I've begun working on Issue 1276. I've added Request and Response info to the AddEdit dialog box and the Breakpoint message. I'd appreciate some guidance on two things:

First, I haven't been able to find the WebSocket breakpoint processing. I assume it uses the extensions.brk package, but haven't been able to track down references. Could you tell me the package name(s) where WebSocket is located?

Second, I'm still not clear on the exact functionality to be added to breakpoints for request/response processing. It seems like there's already the ability in Custom Breakpoints to specify a breakpoint related to the request or response header and body. I don't see the ability to break on all requests or responses separately, only on both.Any explanation would be helpful...

Dave

[kingthorin+owaspzap]

Hi Dave, I can't speak to the first item, but for the second that's kind of the point of issue 1276. Right now it's both, 1276 is meant to implemented new functionality to allow breaking on:

1. Only requests.
2. Only responses.
3. Both.

[psiinon]

Hi Dave,

We try to implement as much functionality in the zap-extensions project - that way we can upgrade the add-ons much more easily.
The Web Sockets support in in the zap-extensions trunk: https://code.google.com/p/zap-extensions/source/browse/#svn%2Ftrunk%2Fsrc%2Forg%2Fzaproxy%2Fzap%2Fextension%2Fwebsocket

As Kingthorin said, we dont currently have the ability to break on just requests or responses, so thats also part of this issue :)

Cheers,

Simon

[Dave Hutira]

OK, now I’m confused; but, I’ve heard that acknowledging ignorance is the beginning of wisdom, so…

It seems like adding Request and Response checkboxes to the Custom Breakpoint panel was the wrong thing to do; I’ve reverted these changes out…

In the current version 2.3.1, I already see separate Request and Response breakpoint buttons:

In the current Dev version, I see the ability ( through the Tools – Options – Breakpoints menu choice ) to choose to display either separate Request/Response breakpoint buttons, or a combined button:

This choice isn’t in the 2.3.1 version.

So, it seems like separate Request/Response breakpoint buttons already are in the current version, and have been enhanced in the upcoming version. Am I misunderstanding something about Issue 1276?

All comments are appreciated…

[psiinon]

Hi Dave,

Your Custom Break point changes were the right approach - quick, put them back! ;)
The ability to break on _all_ requests and responses has always been in ZAP, I just changed the dev version recently as per https://groups.google.com/d/msg/zaproxy-develop/Muz30VI3ATA/fq3utkWuGwgJ

However there are many times when you dont want to break on all requests or responses - eg for an ajax application which is making loads of requests in the background.
So custom break points allow you to specify a more fine grained set of criteria so that ZAP will only break on the requests or responses you want to intercept.
However right now it will break on _both_ requests and responses that match your criteria, you cant specify one or the other.
Thats what this enhancement is about - allowing the user to specify whether the custom break point should apply to just requests, just responses or both.

Does that make sense now?

Simon

[Dave Hutira]

Hi Simon,

I think we're almost there...;)...Thank You for your help...

I do see the current ability to specify a custom breakpoint on request or response headers and bodies:



Should the new request/response processing be more generic that this, like maybe break if the criteria string is anywhere in the request/response? If so, the new request/response checkboxes should be overriding the match choice?

Sorry if I'm making this harder than it needs to be, I just like to get the details straight before coding; makes it easier to know when the solution is complete....

Thanks again,
Dave

[Dave Hutira]

Here's the picture for my previous post....It should go after the second line...

[kingthorin+owaspzap]

Simon correct me if I'm wrong but I think 1276 was meant to add options to the first button of the set:

• "Set break on all requests and responses"
• "Submit and step to next request or response"
• "Submit and continue to next break point"
• "Bin request and response"
• "Add custom HTTP break point..."

So that it would have either a dropdown or four states:

• Off
  
• On (Requests and Responses)
  
• On (Requests)
• On (Responses)

I'm not much of a UI person but if we're going with multiple states vs. a dropdown then how about something like:

Off == Green, On (Both) == Red, On (Requests) == Left half red, On (Responses) == Right half red. (May that isn't noticeable enough, perhaps it should be a green/red mix....I dunno).

[psiinon]

No, I definitely raised 1276 to allow the user to specify whether custom break points referred to requests or responses.
That doesnt mean that we've got the 'main' break UI right yet, so suggestions for that always appreciated :)

Simon

[psiinon]

Ah, good point.

You're right, the Request/Response Header and Body options do allow the user to effectively specify whether the custom break point applies to requests or responses.
But the URL option doesnt :)
So how about we have a 'direction' option (like the Web Sockets dialog):

  Direction:      [ ] Request
                      [ ] Response

If the user selects 'Request Header' or 'Request Body' then the 'Request' checkbox is checked and the Response checkbox is unchecked but both are disabled.
And the equivalent for 'Response Header' and 'Response Body'
In other words they are ignored, but give some feedback to the user.
If the user selects URL then the checkboxes are enabled and actually take effect.
If user should not be able to add a custom break point of type URL with Request and Response unchecked - either the 'Save' button could be disabled or a warning could be shown when its pressed.

Hows that sound?

Simon

[Dave Hutira]

Hi Simon,

That sounds good, and makes sense to me. I'll add the checkboxes to the Add/Edit Custom Breakpoint panel, and add Request and Response flags to the breakpoint message and the breakpoint table model. Then, I'll look at hooking up the processing logic. We can also keep thinking about modifying the toolbars...  

Thanks again for your help, Simon and Kingthorin; talking through the features like this really helps me understand things, and helps keep Zaproxy a well-designed product....

Dave

[Dave Hutira]

Hey Simon,

I've posted a patch for Issue 1276 in the Issues section. I've tested, and things seem to be working; I appreciate your and the team's feedback...

I've also noticed during my testing that the Edit/Remove right-click menu on the breakpoint panel seems to be inconsistent. It seems to ghost-out when I Edit, then Cancel. I'll go ahead and create an issue, then start working on it...

Thanks again for all your help during this process; I've learned alot...

Dave