JADE Environment Development Ideas

We've implemented the development security library for a couple of different purposes (source control in particular).  The implementation of which has evolved over the years.  How the existing hooks were originally implemented by the JADE IDE isn't very flexible, which has made things more difficult as our needs/implementation of a DSL has evolved. 

At the original 'source control summit' meeting circa 2016, some quick win ideas were discussed around these.  One aspect of this was client-execution, the other was about suppressing the message boxes JADE shows.

Since then, the need for changes/improvements in this area has cropped up a couple of times, but there's been some hesitation around making any changes due to effort and/or security concerns from the JADE Plant.  As part of more recent discussions, we've identified a relatively simple ‘opt-in’ approach that provides the desired changes in behaviour, without affecting how the existing hooks are called/implemented.

I'm now raising this as a JEDI to share the proposal with others for their input & support on getting this progressed.

The Problems

The DSL hooks are invoked in serverExecution.  We believe it was implemented this way originally for security reasons.  However, as a result:

• The RAP is at risk of crashing when there's an external exception (the risk of which increases as complexity of DSL grows to cope with session handling while executing in serverExecution).
• We cannot query the schema entity data while it is being locked/updated remotely in the IDE (needed for more sophisticated source control).
• We cannot show forms or interface with external software that would otherwise be possible in clientExecution.

When a DSL hook is rejected, the JADE IDE normally shows its own generic message.  We'd prefer to suppress this in favour of our own more informative message and/or potentially redirect to custom/external functionality in clientExecution.

The Proposal

Define three new external methods in RootSchema (possibly on app or another context object), which would redirect to three new hooks in the DSL.  Unlike the current hooks, these would be defined like an external method with the DskBuffer/DskParam function signature.

The first two methods 'jadeDevelopmentClient’ & 'jadeDevelopmentServer’ would be defined with clientExecution & serverExecution and have the same/similar signature to Object::sendMsgWithParams.  Using jomSendMsg, this would allow a DSL to switch execution context passing a variable parameter list and getting back a result from the server/client.

The third method 'jadeDevelopmentException’ would define a hook for exception handling, which we'd arm locally within the DSL using jomArmExceptionHandler to catch/handle exceptions we may cause externally so we can show an error message & return appropriately.

The Usage

By invoking jadeDevelopmentClient, we'd be able to switch context to clientExecution where we'll be able to handle processing in context of the user thread/session and invoke more advanced functionality.  This removes complexity which puts the RAP at risk as we'd no longer need to carry/manage session information within the server to cope with various threads being used to process DSL requests.

By invoking jadeDevelopmentServer, we'd be able to switch back to the server for any operations that still have to be handled from the server.

Using the exception handler, we'd not only be able to catch our own unexpected exceptions, we'd be able to cause & abort an exception to suppress the generic IDE message/behaviour after it's already been handled in our preferred way.

The Risk

The main concern/hesitation we've heard about from the JADE Plant is the security risk.  By allowing hooks to be called in client execution, we're potentially allowing a malicious developer to gain access by substituting a different DSL in the client node.

This is mitigated by a few things:

• This only applies when the new hooks are used/invoked (the 'opt-in' aspect of this proposal).
• This is of more use/benefit in developer environments, where data security isn't crucial.
• If new hooks are used/invoked in production environments (existing DSL's would continue to work server-side otherwise), it'd presumably be done with awareness of the security implications (as we've highlighted here).  In this scenario, malicious access would be prevented using network security to lock-down fat client bin folders so the DSL couldn't be substituted, and prevent unknown fat clients from connecting to the RAP.

The Reward

We'll have more flexibility to leverage the existing DSL hooks to implement extensions & sophisticated source control, which will work consistently in environments with & without a RAP in use.

Combined with the IDE Extensions proposal, this'd be a relatively simple quick win that'd support integrating our own source control solutions with the IDE for a more seamless user experience.