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" <[EMAIL PROTECTED]> wrote: > > De: Jim Seach [mailto:[EMAIL PROTECTED]] > > 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:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
