[OWASP-ESAPI] Question about Provider/Implementation architecture

Mike Boberski mike.boberski at cox.net
Wed Aug 12 20:20:02 EDT 2009


There are other potential benefits, if one were to read the JCE spec line by
line substituting e.g. "algorithm" for "application data", "keys" for
"patterns", etc. in other words there is additional packaging and coupling
of policy with data and functions that would I think be beneficial. The sole
benefit isn't the ease of bulk loading sets of controls. I can provide a
more detailed proposal/example of what I mean, if folks are interested.

Mike

>
>
>
>
>
> On Wed, Aug 12, 2009 at 6:43 PM, Jim Manico <jim.manico at owasp.org> wrote:
>
>> Assuming that you would have many apps with the same set of sub-providers,
>> you would be able to "bundle" your set inside of one ESAPI master
>> implementation, and initialize it with one call, as an *optional* feature.
>> Whats wrong with that?
>>
>> - Jim
>>
>> ----- Original Message -----
>> From: "Rogan Dawes" <lists at dawes.za.net>
>> To: "Jim Manico" <jim.manico at owasp.org>
>> Cc: <owasp-esapi at lists.owasp.org>
>> Sent: Wednesday, August 12, 2009 12:05 PM
>> Subject: Re: [OWASP-ESAPI] Question about Provider/Implementation
>> architecture
>>
>>
>> > Jim Manico wrote:
>> >> And for what it's worth, I think it would be rather easy to do. We just
>> >> need a master interface that excapsultates the functionality of the
>> >> sub-providers that we already have, and then support...
>> >>
>> >> *ESAPI.addProvider(new com.your.company.ESAPI());*
>> >>
>> >> Then when you implement *com.your.company.ESAPI* it will have to
>> >> implement the master ESAPI interface....
>> >
>> > How is this different to (better than) the current:
>> >
>> > ESAPI.setEncoder(new com.yourcompany.Encoder());
>> >
>> > for the bits you actually want to implement yourself?
>> >
>> > all addProvider would do is:
>> >
>> > public void addProvider(Provider provider) {
>> >    setEncoder(provider.encoder());
>> >    ...
>> > }
>> >
>> > but provider would have to have implementations for EVERY ESAPI
>> > interface, even those where you just want to use the reference.
>> >
>> > Doesn't seem like an improvement to me.
>> >
>> > Rogan
>> >
>>
>> _______________________________________________
>> 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/20090812/a4d9f2db/attachment-0001.html 


More information about the OWASP-ESAPI mailing list