Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB Public Beta Tests » View Thread |
Messages 11 to 14 of 14 total |
Falling into catalog trap... |
Tue, Dec 19 2006 7:38 PM | Permanent Link |
"Ole Willy Tuv" | Michael,
<< If you like to allow several catalog files within a folder, then treat them as schemas, as Ole suggested. >> Having a catalog file that contained the definitions of the schemas contained in the catalog, would be more in line with how these things are defined in the SQL framework. Ole Willy Tuv |
Tue, Dec 19 2006 8:51 PM | Permanent Link |
Michael Baytalsky | Ole,
> << If you like to allow several catalog files within a folder, then treat > them as schemas, as Ole suggested. >> > Having a catalog file that contained the definitions of the schemas > contained in the catalog, would be more in line with how these things are > defined in the SQL framework. Yeah, that makes sense. Having several catalog files was really a weird suggestion on my part, I take it back Michael |
Wed, Dec 20 2006 8:53 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Michael,
<< 1. Binding database to a catalog file *not stored inside the database*. Yes all information ideally should be protected, but the actual data should not depend on configuration for its integrity unless they are stored together and in this case configuration should actually be regarded as data. The whole idea of having to categories: config and data signifies exactly that - one is more important then the other. I don't want to go into details on how painful it could be to support this thing. Rather then arguing I think we should ask users. I see that a few have already experienced that first hand here. >> The configuration information *is* data. It's basically a system-wide catalog file for objects that are not database-specific, i.e. users/roles/jobs. << 2. Binding catalog file name to the database name. People tend to use multiple databases, so one must be able to refer to the same database by different names. Also people tend to name databases the same ('Data' being used in 90% cases). Imagine two independent applications sharing EDB server with both databases designed and shipped to use catalog file named 'data'. >> Forget about this. You're getting hung up on the database catalog naming scheme when the problem is simply that EDB allowed you to do something that it shouldn't allow you to do. Also, two independent applications won't use the same configuration file or server. They will need independent instances of both, just like with DBISAM today. << If you like to allow several catalog files within a folder, then treat them as schemas, as Ole suggested. Although, I must agree, that this feature won't be appreciated or understood by most users It's important to be able to escape to having single default schema. >> Again, the design is not to allow several catalog files within a given folder. It's just a bug that you're allowed to do so. << Regarding roles\users\jobs - they should be defined on server, no doubt about it. However, I'd store their relationship to objects in the database. You don't need to clone any information for that purpose. When you create a new database, you grant permissions to users and only this information is stored in the database. IOW, Catalog stores Users Mike Roles User I.e. it stores the results of grant <role> to <user> >> This is the way it is done. What you're missing, however, is that EDB uses internal IDs (integers) for objects to avoid constantly having to use names and to allow for situations where objects don't actually have proper names. These IDs for roles and users must match those in the configuration file (and the database catalog ID must match that in the configuration file). Mixing database catalogs with configuration files that they don't belong to can cause all sorts of problems with users being authenticated with permissions that they don't actually have, etc. << You can store user names a literals in the database and you don't need to store passwords. This way you don't have to bind the database so tight to the config and it will solve the first issue. >> I'll have to look into this further because there is most likely a lot more here than meets the eye. If it's just a matter of using user/role names instead of IDs, then it might be possible. Might. << Also, there was criticism of storing users and roles on server level: if you deploy two applications and they both define role power_user the name will collide and the user will gain access to another database. >> Again, two applications would not use the same configuration file and/or server instance. << The fact that someone has 1000 identical databases (possibly requires refactoring?) doesn't really justify intentionally wrong design.>> These are processing services. They maintain multiple databases to reduce exposure to downtime for multiple customers. If one customer's database is having trouble, for whatever reason, then other customers are not affected. It is a legitimate design, despite the fact that you don't agree with it. << I'd give it more thought. Maybe it's possible to define shared roles so that all databases could use them or store them on server and then instruct developers to prefix roles they use in database with uri (contextsoft_com_poweruser). >> No, definitely not going to happen. << I've never had to deal with such cases, so it's hard to tell how important they are. These are mostly handled by DBAs for large databases, but if EDB is aiming at the market of zero config databases, then it could become a problem (or the security will not be used - which is more likely if we read poll results on your web site . >> Michael, that's really not particularly funny. I spent a lot of time (months) on the user security aspect of EDB to make it both easy for existing DBISAM users to migrate to and to make it something that is usable for all users. Just because you don't agree with the design does not warrant a comment to the effect that "no one is going to use it". << Server-side session authenticate users when user logs in - both work in the same way as with dbisam. The local session does not authenticate users, it takes whatever user name you provide. For local access, application must implement its own authentication scheme, whatever it could be. It actually could be regarded as a great feature: I for once would appreciate such opportunity immensely - I know that many database apps don't really use database level security because it's hard to coordinate with application-level security, which basically doubles it anyway. >> I'm sorry, but I'm not going to toss out the local user security. It simply isn't going to happen, period. It's as intertwined into the product as the C/S security. In fact, the two are exactly the same thing. << Are you saying that EDB supports file sharing mode? >> Yes, just like DBISAM. -- Tim Young Elevate Software www.elevatesoft.com |
Thu, Dec 21 2006 5:12 AM | Permanent Link |
Michael Baytalsky | Tim,
Thanks, you did clarify it for me. See, I'm easy, once it's explained I will no longer argue The most important thing affecting design decision I guess was that EDB is not designed as a shared server. This is an important assumption and it does affect the design and I didn't realize that. The other thing I didn't realize is that you still have file sharing mode. These are two things that change the perspective - I was just under wrong impression regarding design goals, sorry. Personally, I still don't agree with the issue of catalog to database binding, but that's your choice - I just predict that if you keep it this way, it is going to be the most popular topic in this NG. > Again, the design is not to allow several catalog files within a given > folder. It's just a bug that you're allowed to do so. Yeah, that was silly for me to suggest that > Mixing database catalogs with configuration files that they don't belong to > can cause all sorts of problems with users being authenticated with > permissions that they don't actually have, etc. Only if their names match. This is exactly how it's done in most databases. > exposure to downtime for multiple customers. If one customer's database is > having trouble, for whatever reason, then other customers are not affected. > It is a legitimate design, despite the fact that you don't agree with it. I didn't say I don't agree, I said they might consider refactoring. They just basically treat the database as a document - which is a legitimate use, no doubt about it - but not most efficient from the database perspective. > important they are. These are mostly handled by DBAs for large databases, > but if EDB is aiming at the market of zero config databases, then it could > become a problem (or the security will not be used - which is more likely if > we read poll results on your web site . >> > > Michael, that's really not particularly funny. I spent a lot of time > (months) on the user security aspect of EDB to make it both easy for > existing DBISAM users to migrate to and to make it something that is usable > for all users. Just because you don't agree with the design does not > warrant a comment to the effect that "no one is going to use it". Sorry about that, I do hope people are going to use it, what I was smiling at is it is quite ironic, and actually is a bit funny that one of the least requested features becomes a driving force for many design decisions. I've done it too many times myself, actually Personally, I didn't use the security in DBISAM and probably the only reason for me to begin using it would be if I'm able to provide my own authentication scheme - otherwise, it's too much trouble for me to synchronize database level security with app. level security. Since, as you said, it will be one server per application, then each application can potentially bind database to itself (with signature or whatever), so no other server can access it. Then the database security is no longer needed. > I'm sorry, but I'm not going to toss out the local user security. It simply > isn't going to happen, period. It's as intertwined into the product as the > C/S security. In fact, the two are exactly the same thing. That I understand I just think you should consider that authentication and security are two different things. While security should be implemented everywhere, authentication really only makes sense for servers - when done local it can be easily compromised anyway (not my argument, I read it in firebird embedded readme.txt file . > << Are you saying that EDB supports file sharing mode? >> > Yes, just like DBISAM. Cool. Unexpected. I guess that explains local security also... Regards, Michael |
« Previous Page | Page 2 of 2 | |
Jump to Page: 1 2 |
This web page was last updated on Sunday, May 19, 2024 at 08:46 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |