Latest Blogs

Most have heard the expression ‘ethical hacking’ and understand it applies mainly to the penetration testing of systems to discover their vulnerabilities. For this blog, we are extending the phrase’s meaning to include friendly hacking for a better user experience.

As a consultant at CELCAT, my goal is to find ways to enhance the user experience without resorting to mainstream development.

An overlooked method of doing this is to use database triggers. Of course, whether you can utilise this or not will depend on the built-in error handling within the system; something CELCAT Timetabler does very well.

The Why?

In the case of CELCAT Timetabler, we generally have applications that employ error handling for the database part of an action. In most cases, a simple error message is displayed to the user. Ethically inserting a database trigger allows us to change this behaviour to the advantage of the user.

The How?

Using a database trigger allows us to capture the data before it hits the database and process it according to normal behaviour. In most cases, the trigger can block the action based on user defined parameters set within the trigger, causing a change in how the application handles the data and, when required, the message displayed to the user.

Want to have a go yourself? Did you know you can have as many CELCAT environments as you need at no extra cost? So, set up a test environment and TEST, TEST, TEST, and TEST again, before committing the trigger to production. Alternatively, you can ask us through our contact us page.

Examples
Over the past few months, we have gathered requirements from clients looking for changes to the standard behaviour of the CELCAT Attendance registers. Requirements included: • Enforcing the ‘Staff responsible’ field on the attendance register. • Restricting specific marks within the marking schema to specific staff. • Limiting the changes to a timetable to a specific user and within a specified period.

Here is what the trigger produces:
Example 1: Enforcing the ‘Staff responsible’ field on the attendance register. Standard behaviour, ‘Staff responsible’ field is not populated, register is marked and saved.

Modified behaviour using a database trigger.

Example 2: Restricting marking schema marks to specific staff.

Standard behaviour, all marks within the marking schema available to the marker without exception.

Modified behaviour using a database trigger. The staff are restricted from using the mark and the register cannot be saved.

You’ll know that, within CELCAT Timetabler, we have multiple applications available to complete the same tasks- including Windows, Web and Mobile. Because the modification using triggers is at the database (not application) level, we only apply the trigger once.

The Conclusion

Sadly, this won’t work everywhere and on every application- but where it does, database triggers are a beautiful (yet simple) answer to ethical hacking for the benefit of users. Functionality can be changed without the need to go back to our software supplier and request functional changes.