[OWASP-WEBSCARAB] WebScarab 20060621-003 notes

[Rogan Dawes]

Andrew van der Stock wrote:
> Hi Rogan (and everyone),
> 
> I have tried out the latest version of WebScarab, and I've got some 
> notes for you. :)

GREAT!! FEEDBACK - I LOVE IT!!

> 
> BTW, I like this version better than the earlier versions. I'm seriously 
> going to try and become an ex-Paros user, but I need it to be relatively 
> easy to work with. Paros had a nice learning curve, and I think with by 
> bringing the WebScarab UI back into line with common UI guidelines, I 
> think a easy to learn but deep interface is possible.

Excellent. All feedback is much appreciated.

> Bugs
> 
> Palette - the palette is black on MacOS X. See screen shot. 

 > I don't know how to fix that, but if you like, I can find out.
 >

Yes, this seems to be some kind of bug in MacOS's implementation of 
JDestopPane. It has been quite difficult for me to debug, not having 
access to a Mac. However, the point is moot, I think. I am actually 
planning to move back to the TabbedPane interface from early Webscarab days.

This is partially to address your problem, but also to address the issue 
that we are getting more and more plugins in WebScarab, which are using 
up too much horizontal space in the toolbar, and running off the edge of 
the screen!

> Memory leaks - I will find out from my mates in the J2EE room at work 
> how they diagnose memory leaks. I'm sure you're already working on it.

Well, I have a pretty good idea where it is - if you open up a 
conversation window with a large response in it (e.g. a downloaded jar, 
or doc, or something), and then close it, the memory used by the window 
is not reclaimed. It is very easy to demonstrate now that I have added 
the heap monitor widget ;-)

I'm just not sure what the best way to deal with the problem is . . . :-(

This is certainly a major culprit, which is not to say that others do 
not exist, of course . . .

> Message log - Once the message log is clicked, it cannot be closed. Why?

Well, it should be minimizable - in fact, what you are seeing as black 
blocks in your macOs display are the minimized windows representing the 
various plugins. But the message window should always be available, I 
think, so there is not really any point in closing it.

> 
> Cosmetic
> 
> Menu bars
> 
> In MacOS X, a small amount of repackaging (Stephen De Vries knows 
> exactly how) allows the menu bar to move to the Apple menu without any 
> code changes. This would be great for MacOS X users as it gets us ~ 40 
> vertical pixels back, which on most of the widescreen laptops is 
> absolutely essential.

Ok, I think this is just a packaging issue as you say. However, not 
having access to a Mac means that I can't make the packages my self, and 
am dependent on others to do so for me. Stephen has volunteered to do 
this for WebScarab, so I'm hopeful that new packages will be available soon.

> 
> Tool buttons
> 
> Some of the buttons are preferences. Some are tools. Some are views. I'd 
> suggest only "verbs"=actions / tools go across the top. The other things 
> should be in the menus. Search for example, should just be a text entry 
> box with a "Search" button.

Well, they are all implemented as plugins. So it is basically the case 
that I create the Summary and Message windows, and then each of the 
other buttons is created to represent a different plugin. But yes, you 
are right that this could be reworked a lot.

> Pull down menus
> 
> These should be constrained to be a certain width wide at maximum. I 
> have a screen which is 1400 pixels wide. No other application has near 
> 1400 pixel wide pull down menus.

Are you talking about menus or comboboxes? I know that the comboboxes 
are pretty wide, but it makes sense in a way, since the conversations 
summary (id + method + URL + status) can actually take up a lot of space 
. . .

> 
> Message log
> 
> This produces a secondary window which is not properly placed on the 
> screen. It looks like it is part of the lower pane of the underlying 
> screen. It might be best to make this more of a dialog.

It is a free floating JInternalPane. You can drag it around and resize 
it, just as you can with any of the other plugin windows.

> 
> Tools menu
> 
> Has a mixture of options / preferences, and tools. Should be divided 
> into a clear delineation - the Windows, KDE, Gnome, Java, and Mac UI 
> guidelines all suggest that preferences are in the one area.

Makes sense. I'll look into that.

> 
> Tools -> Scripted events
> 
> Has two tree views, but without any nodes to populate either tree, you 
> can't activate the tree and see the  tree nodes. The tree metaphor could 
> very well be the wrong approach here; maybe a left pane for enable and 
> right hand pane is for the properties of the item being selected.

Yes, this doesn't work very well. It is pretty powerful, but certainly 
not intuitive. However, you should at least see tree nodes for a variety 
of plugins, Framework, Proxy, etc, and these should be expandable. e.g. 
Proxy has "Connection received", "intercept request" and "intercept 
response" hooks, that can have scripts attached to them. Do you not see 
these nodes?

> 
> Manual Request - this screen requires a very big window. On my G4 
> laptop, it's not big enough. Might I suggest that you use Request and 
> Response on two different pages, either as a master tab? Parsed / raw / 
> hex is a radio button combo anyway - not a tab.

Interesting. It worked fine on my old Dell, at 1024*768. A bit squashed, 
but still usable. I don't like the idea of separating request and 
response onto separate tabs, so that you can't see both at once. How do 
you like the idea of putting them side by side? To see what that would 
look like, open a conversation window, click in one of the fields in the 
request or response, and press Ctrl-T. This will toggle between a 
horizontal and vertical split layout. This won't work in the Manual 
Request, but it could easily be added if people like it.
> 
> That's enough for tonight - I need to do some work before getting to 
> work tomorrow.

Thanks a lot for the feedback. I'll work through it, and post some 
interim solutions to the list for feedback from members.

> What's the best method for dealing with this - should I check out a copy 
> in Eclipse and hack away at the issues? What do you use to code with?

I've been using NetBeans for hacking on the old version of WebScarab, 
primarily because it had the GUI builder. In the new version of 
Webscarab (NG), I'm using Eclipse, so I won't be fussy about whichever 
you prefer.

The EASIEST way to get a copy of the source is to use the tarball on my 
website, which is automatically updated whenever I check something in to 
the GIT repository.

The ideal way to gt a copy of the source is to download Git 
(http://git.or.cz), and clone it:

$ git clone http://dawes.za.net/rogan/webscarab/webscarab.git/

You can keep up to date with:

$ git pull

> thanks,
> Andrew

Regards,

Rogan