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

Jim Manico jim.manico at owasp.org
Sun Aug 8 18:32:19 EDT 2010


The other thing I'd love input on is build automation. More than just maven, I'd love to have the final release zip built via some kind of script. Any thoughts on the best tech for that?

- 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