[Esapi-user] [Esapi-dev] What can I do next for ESAPI?

Jim Manico jim.manico at owasp.org
Sun Aug 8 18:30:15 EDT 2010

I think modularization and documentation are the 2 most important issues to address after ESAPI 2.0 is a production release.

Perhaps we could start simple - like just splitting the core and the reference implementation? That's tricky enough.

Why do we need DI? Do we need a major re-write?

- Jim

On Jul 31, 2010, at 11:12 AM, "Kevin W. Wall" <kevin.w.wall at gmail.com> wrote:

>> There are a couple of outstanding things if I remember correctly.
>> 1) breaking out ESAPI core and components into modules and/or separate
>> jars.
>> In my mind this is one of the most important things we need to work on for
>> future versions. This has been a huge hurdle for a lot of the adopters
>> that I have spoken to, the large number of dependencies introduces
>> a pretty significant amount of risk into getting esapi into existing
>> applications. People should be able to integrate the esapi in smaller
>> pieces to minimize risk and scope of impact on their app.
> True...that's probably (IMHO) *the* most important thing that needs work,
> but it's also a major architectural change (e.g., using dependency injection,
> and ideally separation of config files as well), so I think that's something
> that we, as the ESAPI development needs to discuss a bit more before I or
> anyone else simply dives into it headfirst. And even if we just all agree
> that we will use DI (aka, IoC), then we need to decide if we are going to
> use something like PicoContainer or Spring to implement DI or will we
> write our own DI infrastructure. Lots of stuff to decide here before
> any coding starts.
>> 2) usable contrib components structure.
>> Another important piece. A lot of people are already using libs for a
>> lot of these concerns and it would make adoption a great deal easier if
>> they could drop a contrib jar into the classpath, make some configuration
>> changes and have a working component based on what they already have -
>> for example Spring Security authentication and access control.
>> I am sure there are more, but these are some of the larger more impactful
>> changes that we have talked about.
> Now that you mention it, I did think of maybe working on a contrib component
> for Acegi Security for their LdapAuthenticationProvider. (Most people use
> Acegi for Spring, right?) However, I thought it would make sense to do it
> separate from Spring so that someone could use it if they were only using
> Acegi and not using Spring. (I think I know a few cases at Qwest where that's
> true.)
> But, OTOH, it looks as though none of the contrib components even exist
> yet. So before I start on anything like that, I would want to know how
> we intend to deliver this contrib? Specifically, do we assume we need to
> deliver any dependencies or can we just have a (separate?) pom.xml and have
> Maven resolve / download all the dependency issues. This would be especially
> relevant if something were done with Spring for example. Also, if there are
> version dependencies, how do we want to handle that? I'm OK w/ just letting
> Maven resolve everything, but there seems to be quite a few ESAPI users who
> are not using Maven and just download the ESAPI .zip file. Also, would we
> make a separate ESAPI-contrib.zip file or include it with ESAPI itself?
> I almost think that if we don't address your issue #1 above, we are either
> going to have to require people use Maven (or perhaps build an RPM or .de
> file for Linux developers and a .msi for Windows users). So in that context,
> #1 seems even more important.
> -kevin
> -- 
> Kevin W. Wall
> "The most likely way for the world to be destroyed, most experts agree,
> is by accident. That's where we come in; we're computer professionals.
> We cause accidents."        -- Nathaniel Borenstein, co-creator of MIME
> _______________________________________________
> Esapi-dev mailing list
> Esapi-dev at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-dev

More information about the Esapi-user mailing list