Abusable Functions in CP, CPMs, and Custom Scripts

When calling create and update functions from within Customer Portal code, the system requires the use of checks via the RightNow\Libraries\AbuseDetection library method isAbuse(), to ensure the CP endpoint is not under a DOS or similar attack. This is helpful, in theory at least, because it ensures that your CP site is mostly protected from these sorts of attack, but this can cause major headaches when building out more complex solutions. 3 out of 4 scenarios below require some level of workaround, depending on your use-case:

Scenario 1 - Standard CP Usage

For standard CP usage, calling the AbuseDetection library works great, as this is its purpose. No problems here.

Scenario 2 - CPM Leveraging a CP Library

When using the CPM management process I recommend, calling libraries within the CP directory tree does not bootstrap CP. In order for your library logic to work regardless of whether it is called from CP or a CPM, an additional check is required. Here's what I use in my CP library code, in case it needs to get called outside of CP and the abuse detection library doesn't exist:

// If being called from CP, unlock abusable APIs
if (class_exists("\RightNow\Libraries\AbuseDetection"))
And CPMs do not, by default, require 'unlocking' abusable functions, so the standard flow of directly triggering object creates and updates work fine.

Scenario 3 - CP Update Triggering a CPM

Here's where things get hairy: if a web request in CP triggers an object save or update, which then triggers some synchronous CPM code that, in turn, calls a save() method there is no way to 'unlock' this save method! Because the original request came in via CP, it requires that abusable functions be unlocked, but because the actual code is running inside the CPM environment, the AbuseDetection library is not available outside of CP!

The Workaround

The only workaround here is to suppress CPMs from firing within the CP logic on object save, then if the CPM logic must run, trigger it directly by calling the necessary library methods.

Scenario 4 - Custom Script

Custom scripts simply do not have a mechanism for unlocking abusable API functions. From the errors and logs generated, this seems to be a slightly different protection mechanism than what is used in Customer Portal, and there is no functionality at this time to allow these methods.

The Workaround

Use a CP controller endpoint to trigger the custom logic, instead of a custom script

Zircon - This is a contributing Drupal Theme
Design by WeebPal.