[OWASP-ESAPI] Using Other Authenticators

Jim Manico jim.manico at owasp.org
Thu Mar 19 14:13:44 EDT 2009


Yep, I'm dropping factories from logging in my next ESAPI sprint - I'm  
almost there.

Jim Manico
jim at manico.net

On Mar 19, 2009, at 2:53 AM, Andrew van der Stock <vanderaj at owasp.org>  
wrote:

> +1 vote for no factories.
>
> Although PHP can re-create the Factory design pattern, PHP doesn't  
> actually have the OO richness to support the Adapter, Factory and  
> Decorator patterns properly without lots of fancy footwork. There's  
> just no bonus for doing it, and lots of performance negatives.
>
> No matter how nice it would be to use fancy OO patterns to make the  
> library less likely to be hand hacked directly, in PHP, it's always  
> simpler to use:
>
> require_once($yourClassGoesHere);
>
> than to create any of these fancy patterns.
>
> Please - more simplicity!
>
> thanks,
> Andrew
>
> On 13/03/2009, at 5:34 AM, Alex Smolen wrote:
>
>> Yeah, perfect, that's what I was getting at. You may want to take a  
>> look at how I do the logging in .NET ESAPI to see one way of  
>> getting rid of the LogFactory.
>>
>> Thanks,
>> Alex
>> On Mar 11, 2009, at 7:18 PM, Jim Manico wrote:
>>
>>> Oh no no no - I do not want to duplicate the Log Factory, in fact  
>>> I think factories are going away.
>>>
>>> I only want to make your choice of Authenticator, Validator, etc.  
>>> implementation be configurable. See the current Java codebase in  
>>> Google, I just checked in a new version of ESAPI.properties that  
>>> lets you configure which log implementation you want to use. It's  
>>> that configuration change that I want to port to the rest of  
>>> ESAPI's major interfaces. Better, Alex?
>>>
>>> - Jim
>>> ----- Original Message -----
>>> From: Alex Smolen
>>> To: Jim Manico ; owasp-esapi at lists.owasp.org
>>> Sent: Wednesday, March 11, 2009 12:38 PM
>>> Subject: re: [OWASP-ESAPI] Using Other Authenticators
>>>
>>> So if I understand your suggested change, you are proposing that  
>>> we change several classes to follow the current Java ESAPI logging  
>>> implementation that has a separate JavaLogFactory class.
>>>
>>> I think that this approach is overkill. If you look at the ESAPI  
>>> architecture, the ESAPI class itself is sort of a factory (http://en.wikipedia.org/wiki/Factory_method_pattern 
>>> ). Its methods return an Interface which can be changed to a  
>>> particular implementation. However, right now, you have to change  
>>> the code in that class to return your own preferred  
>>> implementation. I suggest that you change that ESAPI class to  
>>> accept something from the configuration file to determine what  
>>> class to load for each particular function (Authenticator,  
>>> Validator, etc). Then, you don't need JavaLogFactory or any other  
>>> factories.
>>>
>>> i.e. rather than this
>>>
>>>     public static Encryptor encryptor() {
>>>         if (ESAPI.encryptor == null)
>>>             ESAPI.encryptor = new JavaEncryptor();
>>>         return ESAPI.encryptor;
>>>     }
>>>
>>> do this
>>>
>>>      public static Encryptor encryptor() {
>>>         if (ESAPI.encryptor == null)
>>>             ESAPI.encryptor =  
>>> Class. 
>>> forName(securityConfiguration.EncryptorClassName).newInstance();
>>>         return ESAPI.encryptor;
>>>     }
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-esapi/attachments/20090319/4aa28848/attachment.html 


More information about the OWASP-ESAPI mailing list