RE: [PATCH] change JDBCRealm to add flexibility in table layout
De: John Gregg [mailto:[EMAIL PROTECTED]] Enviado el: miércoles 6 de marzo de 2002 15:26 provided, but I consider it an improvement nonetheless because I value flexible designs. I would expect the MySQL users to a flexible design is what you get in JDBCREalm, dont misinterpret me, the db design you've been proposing is the Right One :) I'm not discussing that, but i think flexible design is the one that lets you achieve your goals without modiying the code, i'm achiving your goals without modifying the code, ergo the Actual JDBCRealm is flexible enough to suit your needs, hence proved the first hypotesis.., JDBCRealm is flexible enough already :) Do you want, finally, to solve some flaws in MySql, as the lack of views? well not a problem, but is something that is very bad for my taste ( and my taste was modelled after some of our local gurus) Anyone has other comments? Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] change JDBCRealm to add flexibility in table layout
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! 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? It seems to me that true flexiblilty in our code would be to allow JDBCRealm to work with multiple database designs without requiring the addition of views or modification of table designs. Jim Seach --- Ignacio J. Ortega [EMAIL PROTECTED] wrote: De: John Gregg [mailto:[EMAIL PROTECTED]] Enviado el: miércoles 6 de marzo de 2002 15:26 provided, but I consider it an improvement nonetheless because I value flexible designs. I would expect the MySQL users to a flexible design is what you get in JDBCREalm, dont misinterpret me, the db design you've been proposing is the Right One :) I'm not discussing that, but i think flexible design is the one that lets you achieve your goals without modiying the code, i'm achiving your goals without modifying the code, ergo the Actual JDBCRealm is flexible enough to suit your needs, hence proved the first hypotesis.., JDBCRealm is flexible enough already :) Do you want, finally, to solve some flaws in MySql, as the lack of views? well not a problem, but is something that is very bad for my taste ( and my taste was modelled after some of our local gurus) Anyone has other comments? 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]
RE: [PATCH] change JDBCRealm to add flexibility in table layout
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]
RE: [PATCH] change JDBCRealm to add flexibility in table layout
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]
RE: [PATCH] change JDBCRealm to add flexibility in table layout
De: Jim Seach [mailto:[EMAIL PROTECTED]] Enviado el: jueves 7 de marzo de 2002 16:38 Ignacio, I apologize for not reading more closely. You didn't -1 it, just And i apologize everybody for writing english so bad :), 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. Do you know that Realms in general already have Digest capability inside? Or Are you asking for a new feature? Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] change JDBCRealm to add flexibility in table layout
--- Ignacio J. Ortega [EMAIL PROTECTED] wrote: De: Jim Seach [mailto:[EMAIL PROTECTED]] Enviado el: jueves 7 de marzo de 2002 16:38 Ignacio, I apologize for not reading more closely. You didn't -1 it, just And i apologize everybody for writing english so bad :), Your English is better than my anything else! 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. Do you know that Realms in general already have Digest capability inside? Or Are you asking for a new feature? A new feature, but a suggestion rather than a request. Even if the client realm doesn't support Digest authentication, we can use Basic or Form to get the user ID and password in the clear, then apply the hash function to compare with the hash stored in the database. Using Digest authentication is better, but it may not be an option for all browsers. Maybe some of the Digest code could be reused. Actually, I prefer to authenticate against the database by logging in using the user ID and password supplied, and let the database provide the authentication and access control, but for most databases this doesn't play well with connection pooling. Saludos , Ignacio J. Ortega Jim Seach -- 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]
RE: [PATCH] change JDBCRealm to add flexibility in table layout
Jim, I've been thinking about the custom class for authentication. Basically, that's what JAAS does, so when the JAASRealm is ready from primetime, you'll get your wish. However, I think it's great that Tomcat provides out-of-the-box authentication, even if it's not all things to everyone and I hope there will always be that option. As far as hashed or encrypted passwords goes, I've been thinking about that and think for now a filter would be the way to go, but I'm not sure what the filter would be on! Until my current project, I, too, have always done authentication and authorization by hand but I thought I'd see if I could make my life easier by using the capabilities built-in. Also, we're in agreement over the use of synthetic keys I think. Maybe it wasn't clear from my earlier posts, but I use meaningless ids. Even if my users assure me that such-and-such an attribute is unique and immutable, I'm still inclined to create my own int or long id. I like to create a key generator that relies on the db's sequence facility. I just have one sequence db-wide. I retrieve a batch of keys at once, like 500, and hand them out as requested until they're gone. Then I get another batch. I think I read this in a Scott Ambler paper. This also allows all objects in my application to have an application-wide unique id, which can be useful. Incidentally, different dbs handle sequences differently, which is another reason it's handy to have a key generator interface with multiple implementations that can be plugged-in as needed. Ignacio, You're right, I'm not a views expert. I'm a software developer, not a dba. (-: I try not to rely too much on what the db can do for me in order to maintain a little portability. I've worked on enough projects where we just didn't know what we could afford or where we would deploy. Some of those projects used MySQL, which as you know is somewhat limited feature-wise (ACID transactions, views, etc.) thanks all, john -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] g]On Behalf Of Jim Seach Sent: Thursday, March 07, 2002 9:38 AM To: Tomcat Developers List Subject: RE: [PATCH] change JDBCRealm to add flexibility in table layout 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 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] change JDBCRealm to add flexibility in table layout
De: Jim Seach [mailto:[EMAIL PROTECTED]] Enviado el: jueves 7 de marzo de 2002 18:08 A new feature, but a suggestion rather than a request. Even if the client realm doesn't support Digest authentication, we can use Basic or Form to get the user ID and password in the clear, then apply the hash I was not talking about Digest auth in HTTP sense, sorry for not be clear, i was talking about tc Realms, they already have the ability of use hashed passswords, with selectable hasshing algorithm, right out the box.. Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] change JDBCRealm to add flexibility in table layout
--- Ignacio J. Ortega [EMAIL PROTECTED] wrote: De: Jim Seach [mailto:[EMAIL PROTECTED]] Enviado el: jueves 7 de marzo de 2002 18:08 A new feature, but a suggestion rather than a request. Even if the client realm doesn't support Digest authentication, we can use Basic or Form to get the user ID and password in the clear, then apply the hash I was not talking about Digest auth in HTTP sense, sorry for not be clear, i was talking about tc Realms, they already have the ability of use hashed passswords, with selectable hasshing algorithm, right out the box.. And it is well documented in the Realm-How-To! I swear, I read it before, but for some reason it didn't stick. Sorry! 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]
RE: [PATCH] change JDBCRealm to add flexibility in table layout
I assumed increased flexibility + backwards compatibility would be welcome. After all, Tomcat has to serve the needs of many different users. Some of those users, including me, are working for clients who aren't willing to spend the money on things like WebLogic or Oracle. Instead, we use Tomcat, which works great, and databases like PostgreSQL and MySQL. As you've shown with the views, as a PostgreSQL user, I don't absolutely NEED the patch I've provided, but I consider it an improvement nonetheless because I value flexible designs. I would expect the MySQL users to appreciate a solution that works for everyone, not just everyone else. After this patch, I was considering cleaning up some of the exception handling issues in JDBCRealm, but from now on I'll confine myself to ordinary bug fixes and not design improvements. john -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] g]On Behalf Of Ignacio J. Ortega Sent: Tuesday, March 05, 2002 1:43 PM To: 'Tomcat Developers List'; '[EMAIL PROTECTED]' Subject: RE: [PATCH] change JDBCRealm to add flexibility in table layout ( Syntax aproximated maybe sql-92, more or less ) create table users ( user_id integer not null primary key, user_name varchar(15) not null , user_pass varchar(15) not null ); create table user_roles ( role_id integer not null primary key, user_id integer not null, role_name varchar(15) not null ); create view user_roles_jdbcrealm as select u.user_name,ur.role_name from user_roles ur join users u on (ur.user_id=u.user_id) and use this view in jdbcrealm.. Please add what you need to be able to understand you.. Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] change JDBCRealm to add flexibility in table layout
I conceptually agree with such an approach, especially if the number of users is big (although it's trivial to keep those two table synced in PostgreSQL for small amount of users). But the actual primary keys have to be some sort of synthetic keys (something like SERIAL or a generated key, guaranteed to be unique) rather then 'hand written', which might create problems down the track. For instance, user 'jack' decides that he's going to be 'tom' from now own, but his primary key is still 'jack'. Then another 'jack' comes along and you have a clash of primary keys, which makes it difficult for the database maintenance program (i.e. you have to resort to finding the next one up or something). Is your user database so big that you can't use REFERENCES ... ON UPDATE/DELETE CASCADE to keep those things in sync? Bojan On Thu, 2002-03-07 at 01:25, John Gregg wrote: I assumed increased flexibility + backwards compatibility would be welcome. After all, Tomcat has to serve the needs of many different users. Some of those users, including me, are working for clients who aren't willing to spend the money on things like WebLogic or Oracle. Instead, we use Tomcat, which works great, and databases like PostgreSQL and MySQL. As you've shown with the views, as a PostgreSQL user, I don't absolutely NEED the patch I've provided, but I consider it an improvement nonetheless because I value flexible designs. I would expect the MySQL users to appreciate a solution that works for everyone, not just everyone else. After this patch, I was considering cleaning up some of the exception handling issues in JDBCRealm, but from now on I'll confine myself to ordinary bug fixes and not design improvements. john -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] g]On Behalf Of Ignacio J. Ortega Sent: Tuesday, March 05, 2002 1:43 PM To: 'Tomcat Developers List'; '[EMAIL PROTECTED]' Subject: RE: [PATCH] change JDBCRealm to add flexibility in table layout ( Syntax aproximated maybe sql-92, more or less ) create table users ( user_id integer not null primary key, user_name varchar(15) not null , user_pass varchar(15) not null ); create table user_roles ( role_id integer not null primary key, user_id integer not null, role_name varchar(15) not null ); create view user_roles_jdbcrealm as select u.user_name,ur.role_name from user_roles ur join users u on (ur.user_id=u.user_id) and use this view in jdbcrealm.. Please add what you need to be able to understand you.. Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] change JDBCRealm to add flexibility in table layout
De: John Gregg [mailto:[EMAIL PROTECTED]] Enviado el: martes 5 de marzo de 2002 1:27 in the layout of one's users and roles tables. The current implementation (1.20) assumes the roles table will have a column with the same name and meaning as the username column in the users table. In general, I like to avoid using a column with domain meaning as a primary or foreign key. In Why do not use simply a views, instead of real tables..?? This way you doesnt need to do any changes in JDBCRealm to be able to use whatever column you like to join roles and users tables.. ( that seems what you are looking for , arent you?) If more is needed please explain why.. perhaps i dont understand fully what you need .. And sure, the view method will not work with mysql ( doesnt have views afaik ).., but will for postgress AFAIK.. Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] change JDBCRealm to add flexibility in table layout
Hi Ignacio, I don't see how views will solve this problem. I'm not so much concerned with reading user and role data as I am with updating it. Somehow the two tables need to be linked by some common identifier. The current JDBRealm assumes that identifier is the username. My concern with this is that if a user decides to change his username from iganciojortega to ignacio_j_ortega, I'd also have to change the corresponding records in the roles table and any other table that uses username as a foreign key. This is needlessly error-prone. It requires the developer to track and code for every single such dependency. Instead, I prefer to make the keys be some value that a user will never even know about. So, for example, I would add an 'id' column to each table that serves as the primary key. The roles table would have a foreign key that would contain the value of the id column in the users table. That id would never change, no matter what else changed in the users table. My changes are backwards-compatible. Even if you choose not to design your tables the way I do, you can still leave your data alone and set the userPrimaryKeyCol and userForeignKeyCol to have the same value as userNameCol. In that case, everything will work as it did before. thanks john gregg -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] g]On Behalf Of Ignacio J. Ortega Sent: Tuesday, March 05, 2002 2:45 AM To: 'Tomcat Developers List'; '[EMAIL PROTECTED]' Subject: RE: [PATCH] change JDBCRealm to add flexibility in table layout Why do not use simply a views, instead of real tables..?? This way you doesnt need to do any changes in JDBCRealm to be able to use whatever column you like to join roles and users tables.. ( that seems what you are looking for , arent you?) If more is needed please explain why.. perhaps i dont understand fully what you need .. And sure, the view method will not work with mysql ( doesnt have views afaik ).., but will for postgress AFAIK.. Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] change JDBCRealm to add flexibility in table layout
De: John Gregg [mailto:[EMAIL PROTECTED]] Enviado el: martes 5 de marzo de 2002 20:11 I don't see how views will solve this problem. I'm not so much concerned with reading user and role data as I am with updating it. Somehow the two tables need to be linked by some common identifier. The ( Syntax aproximated maybe sql-92, more or less ) create table users ( user_id integer not null primary key, user_name varchar(15) not null , user_pass varchar(15) not null ); create table user_roles ( role_id integer not null primary key, user_id integer not null, role_name varchar(15) not null ); create view user_roles_jdbcrealm as select u.user_name,ur.role_name from user_roles ur join users u on (ur.user_id=u.user_id) and use this view in jdbcrealm.. Please add what you need to be able to understand you.. Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
