Jiwa

Hi,

There are going to be times when a developer - either writing a plugin or integrating with Jiwa - would benefit from seeing what happens in the Jiwa Application. I'm personally of the opinion we should publish our source code, but until we do there is a way to see how Jiwa ticks without us publishing the source code.

There are numerous .NET compilers around, but the Telerik JustDecompile is one I've used and is at the moment one I will recommend. It's free and does the job.

Once you've installed Telerik JustDecompile, just drag and drop the Jiwa Assembly you're interested in onto it and it will happily show you the decompiled assembly in either C# or VB.NET.

In this screenshot, I've decompiled the JiwaApplication.dll and examined the Logon method of the Manager class:



If you're curious about how we do things, the JustDecompile tool is invaluable to seeing our inner workings.

Mike

Hi Mike,

Thanks for the information .Net Reflector is another tool by Redgate(not free) that will work as well for most .net assemblies and exes and even asp, I agree with your comments on shared knowledge God knows it took Microsoft long enough to realise it.

However I have a question for you in the reverse regarding plugins, how could you go about protecting the code from a plugin being read and or changed if necessary?

A lot of other tools offer Obfuscation techniques is there a way to do this for a plugin in terms of the code and or db connection details?

Part of the reason I am asking this is that given I'm working on a payroll interface as a plugin that we were discussing in another topic, I'm a little bit nervous about anyone getting access to the username and password for that system as well as having any idea of the table structure from the SQL and then being able to access details that they shouldn't have access to, as in this case shared knowledge would not be a good idea.

Hi Stuart,

Initially we were going to provide a mechanism to encrypt the plugin code, and use a password / passphrase / token to be supplied in order to view or edit plugins. But, we backed away from that idea as we feared it may cause more problems than it solved.

The long term vision is to provide some form of security for this, but for now it's clear text.

There are a few approaches you can take to secure sensitive information.

In your case of a plugin containing credentials to a wages database, you could do away with SQL authentication when making the connection to the wages database and instead use Windows authentication. You would need to make sure a windows user is created with sufficient access to the wages database, and that the plugin scheduler service is configured to use that windows user. This will allow the plugin to operate, but anybody viewing the plugin will not be able to glean sensitive credential information.

Another layer of security is to use the built-in permissions in Jiwa to not let unprivileged users load the plugin maintenance form at all.

Another layer above that, if you want to restrict view/edit access to certain plugins, but not all plugins is to make another plugin which hooks into the plugin maintenance form and if the user is trying to read the "Wages Integration Plugin" - or any other nominated plugin, prompt for a username and password of a user with a the appropriate custom abstract permission. This will allow only certain plugins to be viewed or edited by nominated users.

An example of a permission override plugin is posted here - it's hooked into the sales order form, but can easily be modified to hook into the plugin maintenance form instead. Creating a custom abstract permissions is as simple as a single insert query into the appropriate table (SY_FormAbstractPermissions I think?) and then setting the permission to the groups you want.

Hope this is of some help,

Mike

Hi Mike,

Thanks for the extremely quick reply, given I am new to doing the plugins, is it possible to call another .net assembly that could do the work and still be Obfuscatted?

What I am thinking of it that way if the dll was handed the details encrypted for the db it could possibly just hand back some sort of result set to work with and then have the exposed code do the journal with the rolled up data that wouldn't be at the individual level.

SBarnes wrote:is it possible to call another .net assembly that could do the work and still be Obfuscatted?

What I am thinking of it that way if the dll was handed the details encrypted for the db it could possibly just hand back some sort of result set to work with and then have the exposed code do the journal with the rolled up data that wouldn't be at the individual level.

Of course! You can write your own assembly, obfuscate it and call that from within the plugin .

The two drawbacks are:
1. Your assembly will be obfuscated, so the plugin would need to be using the gibberish looking method name - no big deal.
2. You will need to manually place the obfuscated assembly in the Jiwa Financials program folder (again, not such a big deal).

EDIT: You no longer need to manually deploy your own assemblies with the introduction of embedded references.

Mike