Monday, 24 November 2014

CentralPark 1.8.2644.5566 is available

You can download it here.

Release note:

Features:
- Added support for ODBC data sources to the Import Definitions. 

Improvements:
- CATS SSVS plugin improvements to cater for 
 - Altering the file date
 - Setting either the Account Details or "Creditor or Debtor Code" not both at the same time.

Bug Fixes:
- When importing transactions with 4 decimal places hashes were failing, since CP uses 2 decimal places. (This will only occur if your import definition query returns amounts to more than 2 decimal places.)

NOTES:
- When using the ODBC data sources one should choose the option in the "Query Type" field. The query that one generates will need to specify the key field parameter as a '?' as shown in the sample screenshot below.



Monday, 10 November 2014

CentralPark 1.8.2637.5550 is available

You can download it here.

Release note:

Improvements:
- Added an extra config to map Creditor or Debtor code in CATS SSVS
- Downgrade .Net Framework to 4.0 so that CP will work on Windows Server 2003

- Updated WebHelp link. 
Update to the OMNI Payments plugin to not drop off leading 0's on BeneficiaryAccountNumber and Debit Account.

Bug Fixes:
- Critical bug fix dealing with Consolidated Instruction hashes. When consolidated instructions exceeded the Transaction Payments Limit or Transactions Collection Limit on a bank account the split instructions did not have correct hashes. 
- Fixed bug on Run Process screen when filters were applied to Doc Gen Process Definitions.

- Fixed icon on Run Process screen that was showing "disabled" when the checkboxes were actually enabled. 

NOTES:

With this build we have fixed a critical bug with the hashing during consolidation. 

We have also had to downgrade to .Net Framework 4.0. This was due to the fact that .Net Framework 4.5 is not supported on Windows server 2003. In case there are any issues when upgrading here are samples of the web config and service config. Values for <SERVER>, <DATABASE>, <USERNAME> and <PASSWORD> must be set. 

Tuesday, 4 November 2014

CentralPark 1.8.2632.5537 is available

You can download it here.

Release note: 

Improvements:
- Update to the OMNI Payments plugin to not drop off leading 0's on 

Bug Fixes:
- Fixed bug on Run Process screen when filters were applied to Doc Gen Process Definitions.
- Fixed icon on Run Process screen that was showing "disabled" when the checkboxes were actually enabled. 

Thursday, 30 October 2014

CentralPark 1.8.2630.5531 is available

You can download it here.

Release note: 

Improvements:
- Updates / additional config to the StandardBankCATSSSVS plugin.

Bug Fixes:
- Critical bug fix on the Run Process screen when loading Document Generation process definitions. The filter conditions were interfering with other features.

Wednesday, 29 October 2014

CentralPark 1.8.2628.5526 is available

You can download it here.

Release Note:
- Added a new plugin called StandardBankCATSSSVS. This plugin is different to the the existing StandardBankCATS format as it is not a Host-to-Host format. 

Friday, 24 October 2014

CentralPark 1.8.2624.5518 is available

This build replaces version 1.8.2620 as there were some problems with clean installs in that version.

You can download it here.

Tuesday, 21 October 2014

Active Directory Authentication with Windows Authentication

A feature that will allow clients to have some control over user access to CentralPark from Active Directory has been added. 

The concept is that domain administrators can create a group in Active Directory and set domain users as members of this group. When using CentralPark, with Windows Authentication, users can additionally be validated against this group. If the user exists in CentralPark but does not exist in the Active Directory group they will not be allowed access to the application. This assists domain administrators in controlling users access to CentralPark without having to access CentralPark. 

To use the feature the administrator should:

  • Create a group in Active Directory
  • Add the required users as members of the group
  • Confirm that CentralPark is using Windows Authentication
  • Access CentralPark and navigate to Setup -> Options
  • At the bottom of the page is an Active Directory Settings section (Shown below)

  • Set the value for the LDAP server and Allowed User Groups. 
    • Only 1 server name can be specified
    • Multiple user groups can be specified and must be separated by a ; 
  • Test the settings and confirm that a success message is received.
    •  If there is a failure message the values will not be allowed to be saved since that could prevent ALL users from accessing the system, including admins.
  • Save the settings.
Now, when users access CentralPark they will first be validated in CentralPark. If they exist in CentralPark they will be validated against the list of groups in the Allowed User Groups field and if they exist in one of those groups they will be allowed access to CentralPark.  

Upgrading to .Net Framework 4.5

A long overdue .Net Framework update was done in version 1.8.2624. This is a major version update to the framework and as a result requires some changes to the configuration. 

If you are doing a clean install you will not be required to make any framework specific changes. 

However if you are doing an upgrade from an older version to version 1.8.2624 or later please follow the steps outlined in the PDF below. It is advisable to backup your existing config files, at least, until you have the new version up and running.


CentralPark 1.8.2620.5510 is available

This build has been replaced by version 1.8.2624

Release Notes: 

Features:
    * Additional validation of users against an Active Directory group when using Windows Authentication. 
    * Upgraded to .Net Framework 4.5








Tuesday, 14 October 2014

CentralPark 1.8.2615.5499 is available

You can download it here.

Release Notes: 

Improvements:
* Added caching of Script Validations in the front-end and service to improve validation performance. 

Description:

This functionality was tested in a client environment and it made a big difference. A single reported result was process validations that took 10 minutes previously now take less than 1 minute.

The idea behind the change is that we keep a copy of the compiled version of the script validation in a cache. This will save time when executing the validation since we do not have to compile it every time we need it. 

Essentially the way it works is:
- When we need to run a validation we will check the cache
- If the validation does not already exist in the cache
    - we compile it and
    - add it to the cache
- We then load the precompiled version from the cache and run it
- When a validation is changed we update the version in the cache when the user saves the changes
- If a validation is set inactive or deleted we remove it from the cache
- The cache will have the latest versions of the validations precompiled and ready to be used, thus saving compilation time on every use. 


Tuesday, 7 October 2014

Hashing implementation updated and CentralPark 1.8.2613.5495 is available

You can download it here.

After some investigation it was identified that there was an issue with the hashing algorithm related to regional settings. This has been fixed in this version. The previous versions with hashing have been removed. 

If you have installed version 1.8.2605.5471 or 1.8.2611.5488 there may be issues when upgrading to this version or later versions if hashes generated in those version need to be validated in this or later versions. 

Should you encounter these problems please contact Vimesh for assistance. 


Release Notes:

 Improvements:
    * Made Disabled buttons a bit more discoverable
    * Some browser compatibility fixes
    
    Bugs:
    * Made the Hashing algorithm oblivious of the culture. 

Tuesday, 30 September 2014

CentralPark 1.8.2611.5488 is available

You can download it here.

Release Notes: 

Improvements:

  • Streamlined Manual Capture Transaction list page to be more usable and confirmed access to "Pay Beneficiary" and "Add Once Off".
  • Updated required field validations on Manual capture and Beneficiary payment screens.
  • Added a pop-up to show batch details for Document Creation Processes on the Run Process Screen.
  • Updated the control on the Manual Capture Validations screen.
  • Made CP compatible with other browsers namely Chrome and Firefox.
Bugs:

  • Fixed an "object reference" bug when trying to "Import, Enrich and Validate" when there are no transactions to import, enrich or validate. 

Details:

A Usability release was done to make some improvements to screens that users used the most and add value and useful functionality to assist users in their day to day operations. 

The Manual Capture was the place where most work was done since it was a painful point for users. We tried to assist the user to logically understand what is required from them by providing a layout that is more conducive to the task and some validations that would help save time since the backend validation takes long. The idea was to try to assist the user in providing correct information so that backend validation should not have to be repeated.

Along with the items identified above certain filters got a "Show Today" option to easily and quickly filter for today's results which was a very common task performed by users. 

Friday, 12 September 2014

Introducing Transaction and Instruction hashing

The Scenario:


A nefarious user gets access to the database and changes account details or amounts for payments to be made. The Authorisers may not initially pick up that the changes have been made and allow a corrupted payment to be made. 

This has a big impact on business as payments could be erroneously made and they are very difficult if not impossible to undo. 


The Solution:


Verify that the transaction entered or the instruction created have not been tampered with during its progression through the system. 


The Motivation for the Chosen Implementation:


Hashing was chosen as the implementation since it could be implemented without undue risk to existing implementations and it could be done in a way that is entirely secure. 

Hashing is lightweight since it only requires the generation and validation of the hash at key points in the process. It does not require any changes to CentralPark's existing process only the addition of a few columns on existing tables to track the hash. This means that there is no impact on the data and structures of the data, reducing the risk of impacting existing clients' data. 

Creating the hash itself is very efficient and fast and since transaction and instruction data is already being stored the overhead of storing a few extra fields is minimal. 

An added security feature of hashing is that the "key" used in creating the hash is stored within the code, making the computing of hashes very difficult to reverse engineer since the hash does not depend solely on the data visible in the database. 


The Actual Implementation:


When a transaction enters the system via an import or a manual capture, various details of the transaction (including  specifically the account number and amount) are used to compute a unique hash value using a SHA-256 hashing algorithm. This hash is stored along with the transaction. 

Before a transaction is legitimately edited from the front end, the stored hash is validated to verify that the transaction has not been tampered with. Once the legitimate edit is done a new hash is generated for the newly set values. The edit process is logged in CentralPark's history of that transaction. 

At the point of instruction creation the transaction used to create the instruction has its hash validated. This ensures that the transaction was not tampered with as it was processed through the system. The resulting instruction is created along with a hash of its values. This is an 'atomic' step (1 step process) in which the transaction is validated and the instruction and its hash are created. 

Finally, before the instruction is incorporated into an Instruction Document, to be sent to the bank the instructions to be used in the document are all validated against their hashes to confirm that they were not tampered with. 

A comprehensive list of tests were done to validate the integrity of the hashing implementation. Embedded below is a document that describes the tests carried out. These tests were run in an attempt simulate what a user may do to try to push through an invalid transaction. 




The Exceptions:


If a hash validation fails for a transaction or instruction, the running process will be aborted as a failure and the offending transactions or instructions will be logged in an error table. Exceptions can then be viewed via a new screen in the Admin menu called Hash Validation Failures.


The Performance:


Numerous tests were done on batches from 10 - 50000 - 200 000 transactions that were Imported and processed through to an Instruction Document being created. The performance degradation in labs tests was approximately 12% on batches of 50 000 and 6% on Batches of 200 000.


Thursday, 11 September 2014

CentralPark 1.8.2605.5471 is available

You can download it here.

Release Notes:

  • Added Transaction and Instruction Hashing.

Thursday, 21 August 2014

CentralPark 1.8.2602.5456 is available

You can download it here.

Release Notes:

  • Improved Duplicate Validation performance.