WIP: Support asynchronous operations (promises)

[tlwr]

Summary

More details in #79

I've managed so far to keep it as backwards compatible as possible, there are no configuration changes needed for any operations.

Functionality example

An operation could only look like this before:

myOp: function(input, args) {
  var a = doSomething();
  if (a.err) {
    throw a.err;
  }
  return doSomethingElse(a);
}

But if doSomething was asynchronous then we would not be able to use it...

Now we can also do:

myAsyncOp: function(input, args) {
  return new Promise(function(resolve, reject) {
    doAsyncSomething()
    .then(function(a) {
      resolve(doSomethingElse(a));
    })
    .catch(function(err) {
      reject(err)
    });
  };
}

Operational example

I have added an operation called "Wait", this is what it looks like when an operation is in progress:

I'd love your feedback on how I can improve this, or if you find any bugs (and because it is quite a large functionality change I do expect there to be some fiddly edge-cases).

[n1474335]

This is brilliant work and something that I've wanted to get sorted out for a while. When I've got a bit of spare time I'll go through it in detail and try to find edge cases where it causes problems, but for now just wanted to give a big thumbs up. We'll definitely get this merged once we've had a chance to test it thoroughly.

[tlwr]

Because this is a big change it would seem like a good time to add some functionality for testing operations. To keep with the very simple and lightweight structure of CyberChef it would be nice to not have to pull in tools like Selenium and PhantomJS just to test operations.

I hacked together a quick implementation to help test the above changes and I think it makes sense to actually have this functionality permanently (and for all operations).

My very simple implementation.

1. Run grunt test
2. Open browser to the test build
3. The tests are run and the user can see which tests are passing/failing/erroring.

The actual CyberChef code doesn't have to be modified to enable this functionality because of the separation of the actual HTMLApp and Chef/Recipe/etc.

• → means the test is still running
• ✓ means the test is passing.
• ! means the test is failing (The output and the expectedOutput differ).
• ❌ means the test is erroring when it should not (expectedError is false or undefined).

Tests are currently defined (all together) in a list, each test is defined like so:

    {   
        name:"Fork & Merge nothing",
        input: "", 
        expectedOutput: "", 
        expectedError: false,
        recipeConfig: [
            {   
                op: "Fork",
                args: ["\n", "\n", false],
            },  
            {   
                op: "Merge",
                args: [], 
            },  
        ]   
    }

The recipeConfig is as it is elsewhere in the codebase (and the URL).

The expectedOutput is what it will test the actual output against.

The expectedError (optional) is for cases when we should expect an error (e.g. "To base" with a non-number).

---

Should I commit it (after cleaning it the code a bit), if so, should I put it here or in another PR?

[n1474335]

Another thing I can take off my to do list. Yes, definitely commit this. I'd put it in a separate pull request as it's not strictly linked to this one.

[tlwr]

Glad to lighten the load; moved this into it's own PR #84.

[n1474335]

I have made a few largely aesthetic changes and created a new branch, feature-async-ops to work on this longer term. There are a few things which prevent us from merging it into master just at the moment, including:

• There are some bugs surrounding some of the Flow Control operations, particularly 'Conditional Jump'. I want to make sure this is fully tested before we roll it out and that will be a lot easier once the test runner has been merged, so we'll get that sorted out first.
• Using promises means that we'll loose support for a lot of browsers. CyberChef is fairly forward leaning so I'm not massively concerned about support for very old browsers, but this is a pretty drastic step up. We should think about how to improve backwards compatibility (perhaps by using something like Babel) before we go ahead and merge this into the production version.
• It would be nice to make better use of this functionality, perhaps by adding the ability to cancel bakes if they are taking too long (at least those that are asynchronous). This could require quite a bit more work and I think we should thrash that out in the new branch and then perhaps up the major version number when we eventually merge it into master.

For now I will close this PR - all new work should be merged into feature-async-ops. Thanks very much for getting the ball rolling, this is very promising.