I believe that IDOC script gets a bad rap. On more then one occasion I have witnessed eyes roll when we began explaining how the Stellent scripting language can be used during an implementation. It’s a natural reaction as most developers would probably rather work in a more mainstream language then learning some new proprietary, sort of ”cold-fusion” looking one. And while I’m sure there are quite a few implementations done with 100% IDOC-based customizations, my personal preference is to use Java/JSP as the primary languge, with use of IDOC for presentation and configuration scripting. In this ancillary role I’ve grown quite an affinity for the IDOC and as I’ll demonstrate in the example component(Security Overrides), try to IDOC-enable my Java-based components and customizations.
The concept behind the example component, Security Overrides, is an IDOC enabled version of the Security Filter example, which is part of Stellent’s HowToComponents Bundle. Stellent’s SecurityFilter component is an example of how to use the alterUserCredentials filter to change the rights of a user during a specific service request. The primary example is the BlackHole check in example which grants everyone write access when checking in an item using the Black Hole service.
Creating security filters or overrides with the alterUserCredentials can be a tricky proposition. Depending on your implementation, you’re basically altering the behavior of the content server with no real visible indication that it’s being done. In addition the alterUserCredentials filter is called with every service call, so it’s a great place to cause a performance problem with inefficient code, or just by adding multiple security filter components.
So how does the Security Overrides component and more importantly IDOC help the situation? The component creates a central, administrator controlled, interface for creating and managing overrides. What’s more, each service configured has an IDOC script prompt, which is used in the final decisioning of whether to apply the override or not. For example if an administrator desired to only allow the “sysadmin” account access to the providers page, they would configure an override that removed all permissions for the “GET_ALL_PROVIDERS” service. In the IDOC prompt script would be added to evaluate the dUser variable, ensuring it was the “sysadmin” account.
The beautiful thing here is that because the component is processing IDOC for it’s final decsioning logic, the override becomes extremely simple to alter as well as include addtional actions down the road if desired. And as you’ll see in the code, creating a component which can support IDOC scripting takes very little additional work.
In addition to integrating IDOC scripting in a Java-based component, the component also demonstrates:
- Creating an installation filter, which creates a database table after start up
- Working with the YUI library to create a model, pop-up form as well as creating and handling AJAX requests
- The run-time creation and altering of environment variables
- Customizing the Stellent / Oracle interface
As you might have guessed from the word “Introduction” in the title, I plan on making the review of this component a multi-part series, rather then one long post. The component along with it’s source code will be available for download here.
I should also mention that Oracle has a fully supported component available for download which has some of the same features as this one. It’s called the “Need to Know” component and if you are considering using my example in a production system, please take a look at their component first.
