[OWASP-ESAPI] ESAPI Access

Jim Manico jim.manico at owasp.org
Mon Aug 3 01:27:11 EDT 2009


> Personally I think it's easier to manage if it's all together. 

I totally agree - especially for this upcoming 2.0 release. Maybe we can reconsider after 2.0 is very stable...

+1 in support of the TCK approach (perhaps for ESAPI 3.0?)

- Jim
  ----- Original Message ----- 
  From: Jeff Williams 
  To: 'Neil Matatall' ; 'Kevin W. Wall' 
  Cc: owasp-esapi at lists.owasp.org 
  Sent: Monday, July 27, 2009 8:03 AM
  Subject: Re: [OWASP-ESAPI] ESAPI Access


  I'm open to either approach, as long as we are all on board.  Personally I think it's easier to manage if it's all together.  One possible solution would be to keep all the code together, but create separate jar files during the build process.  One for the API and the other with the full reference implementation.

   

  Long term, I'm hoping that we can do something like what Java did with the TCK (Tech Compatibility Kit). Essentially, create a kit that contains 1) a standard with definitions of what the API is supposed to do, 2) test cases to verify that an implementation actually does it, 3) a reference implementation that passes the tests.

   

  In the ideal world, the TCK approach would be roughly the same across the different language implementations, so that the test cases can be reused.  For now, however, I think we're spending our resources right.

   

  --Jeff

   

   

  From: owasp-esapi-bounces at lists.owasp.org [mailto:owasp-esapi-bounces at lists.owasp.org] On Behalf Of Neil Matatall
  Sent: Monday, July 27, 2009 12:52 PM
  To: Kevin W. Wall
  Cc: owasp-esapi at lists.owasp.org
  Subject: Re: [OWASP-ESAPI] ESAPI Access

   

  Hello



I like keeping the API as just that, an APII think I lost sight of this.  My idea to drop the reference package name was somewhat motivated by a feeling that there is some really good code in the reference classes that users will want.  As I mentioned before, the validations classes could be used as-is with a little polish.  Others contain chunks of code that other reference implementation developers could benefit from.  I see a great amount of good coming from putting effort into building a framework using some of the reference implementation code.  Otherwise, implementers would probably copy/paste the reference code anyways. 




although that still doesn't solve your naming issue ofgetting rid of the 'reference' in the package nameTurns out the naming wasn't really the issue :)

  I vote to keep everything together as is (using reference as a marker) and evaluate what can be used to build an esapi "framework" that will lessen the burden on implementers which will help them avoid some of the very common pitfalls that the API itself can't prevent.  I will try and find some concrete examples of this.    

  My only reservation about splitting the projects in two is manageability and conflicts during changes, which I really don't mind.  I've seen projects succeed using both strategies.  


  What do you think?
  I think 


  Neil


  Kevin W. Wall wrote: 

Chris Schmidt wrote:  I think we should seperate out the reference implementation into it'sown subproject. I like keeping the API as just that, an API. Why don't we create a subproject for the RI and give it an officialname? On Sat, 2009-07-25 at 13:24 -1000, Jim Manico wrote:    I think, really, ESAPI is just a set of required interfaces to solve common appsec issues. Some of the reference implementation can be used as is (the utility classes). And some of ESAPI really needs to be customized for your org (auth and access control, primarily). Perhaps we can split things into Core Interfaces, General Utilties, and Reference Implementation classes? - Jim       I agree with Jim. I think it is unlikely that some of these non-interfaceconcrete utility classes will likely never be customized / replaced evenif that is allowed. So how would you decide which concrete classes to keep in ESAPI and whichto move to another subproject? And isn't this likely to also makeworking on those classes more of a pain in the butt since usuallywe would need to work with both of them?? If all you wishto do is to separate out the reference classes in org.owasp.esapi.referenceto a separate jar file (say 'esapi-ref.jar'), then I could live withthat I guess, although that still doesn't solve your naming issue ofgetting rid of the 'reference' in the package name, unless you wantto rename that package to something like 'org.owasp.esapi_ref' and thenmove them to a separate jar. I guess I could live with that, but ifwe are going to do that, why even have a separate jar? Why notjust re-factor them to 'org.owasp.esapi_ref' package? As much asI hate underscores in package names, I'd prefer that over splittingthings into two separate projects...at least at this point. -kevin   



------------------------------------------------------------------------------


  _______________________________________________
  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/20090802/9ea07bdf/attachment.html 


More information about the OWASP-ESAPI mailing list