[OWASP-ESAPI] Using Other Authenticators

[Alex Smolen]

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;
>     }
>
> I think creating extra factories is unnecssary. The JavaLogFactory  
> isn't necessary for what you're trying to do (support different  
> types of logging engines). You have two different factories - one  
> for a LogFactory, and one for Loggers. You can simply extend Logger  
> to do whatever you want and get rid of the LogFactory class.
>
> -Alex
>
> From: "Jim Manico" <jim.manico at owasp.org>
> Sent: Wednesday, March 11, 2009 11:39 AM
> To: owasp-esapi at lists.owasp.org
> Subject: [OWASP-ESAPI] Using Other Authenticators
>
> On the topic of using your own Authentication mechanism inside of  
> ESAPI; I'm currently working on a few changes in ESAPI that will  
> allow you to specify your own implementation at configuration time.
>
> For example, I've recently checked a new logger into ESAPI -  
> Log4JLogFactory. We already have JavaLogFactory.I built a mechanism  
> so that either can be specificed at config time in ESAPI.properties  
> like so:
>
> Implementation.Logger=org.owasp.esapi.reference.JavaLogFactory
>
> or
>
> Implementation'Logger=org.owasp.esapi.reference.JavaLogFactory
>
>
> I'm going to explode the same concept out Authenticator, Validator  
> and all the other top-level classes of ESAPI.
>
> Cool?
>
> - Jim
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-esapi/attachments/20090312/3ad485bc/attachment.html