Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Message-ID: <20020307153801.72701.qmail@web20102.mail.yahoo.com>
Date: Thu, 7 Mar 2002 07:38:01 -0800 (PST)
From: Jim Seach <jwseach@yahoo.com>
Subject: RE: [PATCH] change JDBCRealm to add flexibility in table layout
To: Tomcat Developers List <tomcat-dev@jakarta.apache.org>
In-Reply-To: <80F5674514B4D311BAFC0040F6A45EEE24367B@ntserver>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Ignacio,

I apologize for not reading more closely.  You didn't -1 it, just
expressed your opinion.  I agree your proposed changes would be much
more flexible.  Another option that might be nice would be the ability
to specify a user supplied class to compute a password hash so only the
hash needs to be stored in the database rather than the actual
password.

I usually use custom authentication rather than using the container
provided capabilities, but there may be times when this might be
useful, so having well thought out and flexible components is always
important!

Thanks,

Jim Seach

--- "Ignacio J. Ortega" <nacho@siapi.es> wrote:
> > De: Jim Seach [mailto:jwseach@yahoo.com]
> > Enviado el: jueves 7 de marzo de 2002 14:16
> 
> > 
> > Ignacio,
> > 
> > Forgive me if I don't understand, but it appears you are saying
> that
> > JDBCRealm's use of a sub-optimal table design is *flexible* because
> > there are ways in some databases to modify a correct schema (by
> adding
> > a view) to make it work with JDBCRealm?  It seems to me in this
> case
> > that it is the database that is being flexible not JDBCRealm!
> > 
> 
> This is right.. 
> 
> But just now JDBCRealm only need the information it gets from the db,
> users, passwords and roles, why mess a simple but efective design
> with
> another that doenst adds a high degree of flexibility ( although it
> patterns data in a way that seems correct to everybody including me
> )????, i'm only saying that the explanation supporting this patch
> were
> not correct..John stated in his first messages, that views doesnt
> solve
> his problem.. this is not right, views do solve his problem.. 
> 
> > In other words, users of databases such as MySQL or small pure Java
> > databases like HSQL or McCoi are out of luck because we refuse a
> > *backward compatible* patch that would allow them to work with
> their
> > existing, correct db design?
> > 
> 
> We have not refused nothing, nobody has committed it, so until now,
> we
> are only speaking, i'm not the only how can  commit the patch, btw it
> seems working for me, so i will not -1 it, simply i dont like it..
> but
> this is just my opinion..
> 
> Instead i would be glad to champion and commit a patch that do solve
> a
> more broad version of the problem, not just adding another layer of
> indirection to the relation between roles and users.. this can be
> done
> in the db if needed, it's not a flaw or inflexibility in the
> JDBCRealm,
> is a flaw in a db..
> 
> What i would like to see in a patch to JDBCRealm?
> 
> Add a UserSql attribute to JDBCRealm to be used instead of composing
> internally a select, and the same for the roles, this could solve a
> broader range of problems, than this patch solves by itself.. and
> will
> make JDBCRealm compatible with any other past or future db.. and will
> scartch my own itches.. probably if nobody takes over that i will
> last
> doing it this way, if nobody complaints, but any help is welcomed as
> ever..
> 
> 
> Saludos ,
> Ignacio J. Ortega
> 
> 
> --
> To unsubscribe, e-mail:  
> <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:tomcat-dev-help@jakarta.apache.org>
> 


__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/

--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>