[Discussion] WebUI Redesign

[hackathi]

So, let's talk about the WebUI for a bit, shall we?

Currently, we have a WebUI that... does the job. Kind of. We see failures, an overall completion percentage, a percentage of current step completion, and can open the log for any failure if we knew the test case number.

Implementation-wise, it's a super-simple js file which bombards boofuzz running flask API with requests. Nothing fancy, but it does the job.

However, I have two main issues (and one little-spoiled-brat issue) with it:

• I can't navigate testcases logically by Name, Block or whatever, despite boofuzz internal data structure should make this possible (it's a tree after all!)
• Overall statistics (Testcases/sec, Failed/passed percentage, not-application-crashes-but-other-failures - for when you accidentally fuzz your network device instead of your target, ETA for both overall & current teststep) are nonexistant
• It ain't pretty (which includes "It ain't responsive", so I have trouble fitting it on 25% of my status dash screen)

To address all of the above, I propose a re-write in modern web technology (tm) (R). Specifically: vue.js and bootstrap4.

Why is this a Discussion Issue? Because doing so would add a build-time dependency on node.js, and a load of other dependencies besides vue and bootstrap (axios, vue-bootstrap, vue-speedometer, ... come to mind). These things need to be integrated in some shape or form into a mostly python-only codebase, which I'm no expert in.

Also, to use all of these nice new things, the current API is insufficient, and needs to be expanded. I don't have a particular plan there just yet, however websockets would be nice to stop polling. Not that it matters on localhost anyway, but still.

Alas, if we do want to make that happen, here are the steps I propose:

1. Replace the existing WebUI with basically the same design & functionality, but in vue + bootstrap + axios. --> [WIP] WebUI: vuejs #491
2. Rewrite the API (/api/v2/) and make the tree structure accessible.
3. Add new Features to the WebUI

If noone has any objections, I'll probably start some work on (1) and share whatever I come up with in a PR, where we can discuss technical details.

Cheers,
Katharina

[jtpereyda]

I agree with your 3 main issues.

The node dependency is a tradeoff; I always figured we'd have to use a bunch of JS tech though if we modrenized the UI. I think the fuzzer should still function as a Python package apart from Node, with the web UI as an optional addon. Now, preferably we can also make it easy to install, maybe even working by default. Not sure how those details would pan out. Perhaps just a boofuzz-ui NPM package or something.

Feel free to add functionality to the existing API without needing to solidify too soon. With a functioning API, we can work on the frontend and backend in spurts as needed.

[hackathi]

As far as I'm concerned, node is required for those that publish packages to pypi, or build the entirety of boofuzz themselves. Once built, node isn't needed at all. The build process spurts out a html page and some (albeit heavy) javascript files, that can be served by flask like it is done now. I'm more concerned about actually tracking dependencies and issues with them. The node stuff is notorious to report a bunch of vulnerabilities, so it would make sense to semi-automate updating (or at least, create issues). I know that there are bots out there that do that, I just don't know how to use them, what's the best, and stuff.

I'm no fan of splitting the codebase. If anything, I'd just add a npm build to whatever pipeline we use to publish the package, and be done. No node dependency for anybody that doesn't touch the web interface or the API.

[SR4ven]

While browsing through the open issues, I came across #284.
Maybe we can fix that in case we touch the backend.

[SR4ven]

#66 also appears to be related

[jtpereyda]

Re the tree topic -- I'm adding combinatorial functionality, which allows the number of test cases to go much higher much quicker. In this mode, recording every single test case becomes burdensome (my DB was at several gigs within an hour)... which makes navigating passed test cases less important.

Also, once you get to tuples of 2 cases, the tree view is a less intuitive way to navigate test cases (still possible in theory though).

However, the tree view would still provide a handy conceptual view of the protocol under test. But it might be more of a static view of the protocol?

[jtpereyda]

The combinatorial (and therefore unbounded) approach will also mean there's no end, so the progress bars will change.