Home Projects Jobs Clientele Contact


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: UU Database

Frankly, I don't really care - which way we assign a role to a user. We may have the table that translates a user name/password into a role. Or, we can go any other way. The important part is - we shouldn't work with users, but only with roles. When a user John Doe logs in the webface - he provides a user name/password. We verify his credentials, and set the role for the session. Even if the database doesn't support roles - in this case we may use a database user as a role.

2006/4/12, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:
Alexey Parshin wrote:

>The requirement to verify the stored procs integrity is very
>important. If the server doesn't support such checks - it's pretty
>difficult to enforce. Such checks normally should cut-off the
>debugging time, making some errors to popup during the procedure
>creation (instead of run-time). The alternative is - to write a
>minimal test that should run one proc or a small group of the procs
>after any changes in stored procedures. That should be doable, even if
>I didn't do that before.
Well - we'll need good test suite one way or another.

>The role in traditional databases is a set of access rights. It allows
>to work with few roles 3..15, normally, instead of people, and really
>simplifies the access maintenance. Instead of working with teachers
>John, Ben, and Alex, and admins Dick, Jane, and Bob - we just grant
>the access to DB objects to teacher and/or admin roles, and grant
>these roles to the people. If server doesn't support it, it would be a
Hold on there.. Do you suggest that we create database account
for each user? That is not going to work.
1. It is great security risk (users would actually have knowledge
    of database password, which in turn can easily escalate to
    system compromise)
2. No database will handle such number of users well
3. It will make connection pooling impossible.

There are probably more reasons, but I think ones listed above
cover it pretty well.

Ilya A. Volynets-Evenbakh
Total Knowledge. CTO

Alexey Parshin,

Authoright © Total Knowledge: 2001-2008