[OWASP-ESAPI] ESAPI.NET - Allow custom actions

Paul Apostolescu apbogdan at gmail.com
Wed Aug 26 10:28:47 EDT 2009

The implementation will follow the same pattern as the other
ESAPI.NETcomponents so there will be two ways of adding actions:
- at runtime  : you will always be able to add actions at runtime (via an
AddAction method probably) no matter how the intrusion detector was loaded
- using configuration options:
   - if you do nothing (no config options set) : you get the default meaning
an intrusion detector with all default actions (actions defined in ESAPI
lib) loaded
   - if you add a config element:
           - no actions are loaded by default
           - you can add actions in two ways:
                       - by specifying  an assembly the contains actions :
at load time the loader will look for all classes marked with a special
attribute (ActionAttribute), instantiate
                         and load them. If you want to load the default
ESAPI actions you will have to add the ESAPI assembly itself here.
                       - by specifying an action type : at load time the
loader will create an instance of the type and load it

I think this approach has the right balance between flexibility and ease of
use, it's open but in the same time it doesn't force upon you a particular
way of adding the actions (or do anything for that matter).

Thanks for your feedback.

On Tue, Aug 25, 2009 at 10:20 PM, Chris Schmidt <chrisisbeef at gmail.com>wrote:

> I think this would be a great addition. The main contention point I see
> here is the configuration element. I have never been a fan of obese
> properties files, or properties files in general when referring to classes.
> It makes debugging and tracing code difficult in an age where IDE's have
> made it easy. If we were to implement something like this, I would think
> that we would want to make it something that could be configured either
> programmatically or with a properties/xml file. That way, people could make
> the choice of how to configure their application according to their own
> in-house best practices and code conventions.
> On Tue, Aug 25, 2009 at 3:29 PM, Paul Apostolescu <apbogdan at gmail.com>wrote:
>> All,
>> I think one useful extension point for ESAPI would be to change intrusion
>> detection actions from being predefined string values to objects
>> implementing a standard interface called IAction (for example). The
>> motivation is that sometimes you need to do more then just a simple logout -
>> for example you may want to trigger a more complex web sso logout.
>>  The default implementation will continue to have the already implemented
>> actions but wrapped as IAction instances, and it will also allow consumers
>> to add named custom actions at runtime - much like the validation rules and
>> codes are working today.
>> Let me know what you think.
>> Thanks
>> Paul
>> _______________________________________________
>> OWASP-ESAPI mailing list
>> OWASP-ESAPI at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-esapi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-esapi/attachments/20090826/40b1df1d/attachment.html 

More information about the OWASP-ESAPI mailing list