[Esapi-dev] [Esapi-user] Fwd: ESAPI development process

[Jim Manico]

I back this with one small change. Instead of:

ESAPI.accessController(String named)

Should we consider 

ESAPI.accessController(Class class)
ESAPI.accessController(AccessController class[interface])

?

-----Original Message-----
From: esapi-dev-bounces at lists.owasp.org
[mailto:esapi-dev-bounces at lists.owasp.org] On Behalf Of Chris Schmidt
Sent: Sunday, September 12, 2010 4:17 PM
To: esapi-dev at lists.owasp.org
Subject: Re: [Esapi-dev] [Esapi-user] Fwd: ESAPI development process

  The design flaw is not in the locator itself, the primary design flaw 
is that you can only currently have a single instance of any of the 
ESAPI interfaces, which is severely limiting. In the process of 
modularization the idea that I was tossing around was using dependency 
injection to allow for several 'named' singleton or non-singleton 
instances of ESAPI services could be referenced from the locator. I 
think the concept of the locator is an important separation of concern 
aspect of ESAPI that should not go away. Take the following 2 examples 
into consideration:

1.

Class A {
     public void doSomeStuff() throws AccessControlException {
        new ESAPISpringAccessController().assertAuthorized( "A", 
"doSomeStuff" );
        // ... do some stuff
    }
}

Class B {
    public void doSomeOtherStuff() throws AccessControlException {
       new ESAPISpringAccessController().assertAuthorized( "B", 
"doSomeOtherStuff" );
      // ... do some other stuff
    }
}

In this example which is not using the locator - if I one day switch to 
a fully active directory ldap integration for my application (not 
unheard of as an app grows to change Auth/ACL providers) I will need to 
change the code in *both* classes (and any other classes) to use my new 
ESAPIActiveDirectoryAccessController to do the AC check.

2.

Class A {
     public void doSomeStuff() throws AccessControlException {
        ESAPI.accessController().assertAuthorized( "A", "doSomeStuff" );
        // ... do some stuff
    }
}

Class B {
    public void doSomeOtherStuff() throws AccessControlException {
       ESAPI.accessController().assertAuthorized( "B", "doSomeOtherStuff" );
      // ... do some other stuff
    }
}

In the same circumstances described above - I need only change the 
*default* implementation of the Access Controller to use in my security 
configuration. The level of impact for the change is *significantly* less.

That being said, what I envision is the following

ESAPI.accessController()
     Get's an instance the *default* implementation of the access controller

ESAPI.accessController(String name)
     Get's an instance of the *named* access controller

I believe this idea is paramount to the idea of using the ESAPI and 
helps to solve several problems -
     * Having distinct implementation needs where different parts of the 
app need different implementations of ESAPI services
     * Modularization - this will aide greatly in dividing the ESAPI 
into the things that are being used.
     * Plug-in ability - Having DI in place makes creating a plug-in 
type interface a fairly simple task. Since in DI the implementation is 
specified by way of configuration, plugins can either programmatically 
inject themselves into the configuration or they can be manually 
configured or distributed with configurations.

This is just my $0.02



On 9/12/2010 2:45 PM, Jim Manico wrote:
> (moving this to the DEV list)
>
> No disrespect meant to Jeff or anyone else, but I agree that the single
> global ESAPI locator is a significant design mistake for a number of
> reasons.
>
> My plan is to get 2.0 out the door in as stable and secure way as soon as
> possible without any more major architectural changes.
>
> ESAPI 3.0 is going to be a very significant re-write to modularize the
code.
> I'm also certain that the central locater class will go away during this
> process.
>
> Once we get 2.0 at GA, I'll host a design summit (virtual) to begin
planning
> 3.0. I'd love to have your thoughts on that then.
>
> In the meantime, please toss this is the google code tracker under the
> ESAPI-Java project so we do not lose track of it, cool?
>
> - Jim
>
> -----Original Message-----
> From: esapi-user-bounces at lists.owasp.org
> [mailto:esapi-user-bounces at lists.owasp.org] On Behalf Of Patrick Higgins
> Sent: Friday, September 10, 2010 10:55 AM
> To: esapi-user at lists.owasp.org
> Subject: [Esapi-user] Fwd: ESAPI development process
>
> Forwarding to list because I accidentally left it off.
>
> ---------- Forwarded message ----------
> On Fri, Sep 10, 2010 at 8:33 AM, Ed Schaller<schallee at darkmist.net>
wrote:
>> I'm not sure I'd like the codec configurations being unchangeable for
>> all code in a container though.  I may want exceptions to be thrown
>> for invalid characters in some of my code but not in my JSPs. As such I
>> lean toward the factory route or something else where code that wants a
>> codec with certain options can get one without affecting thread safety
>> or codec options for other code.
> My thought on this would be to just create two configurations. I think
> having a single global ESAPI locator is a mistake. It's so easy to
> just declare your own class with static volatile variables to locate
> the configurations you need. For example,
> MyESAPI.JSP_ENCODER.encodeForHTML() and
> MyESAPI.SERVLET_ENCODER.encodeForHTML().
>
> If you need more configurations, just create more instances.
>
> --Patrick
> _______________________________________________
> Esapi-user mailing list
> Esapi-user at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-user
>
> _______________________________________________
> Esapi-dev mailing list
> Esapi-dev at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-dev

_______________________________________________
Esapi-dev mailing list
Esapi-dev at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/esapi-dev