Home Projects Jobs Clientele Contact


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

Re: UU Database

I think, upon user openning the course, we evaluate his rights, determine his position within the course, and assign the appropriate database role. That role is used for a combination user:course.

2006/4/12, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:
Again - let us not confuse database access roles, which fall completely
in domain of DBA, and are outside of the scope of this discussion, and
application access roles. Obviously there will be few different accounts
on live database (i.e. yours, mine, as DBAs, perhaps few other people with
access to look at data, and then the web app account - the one actual
application connects with - that will not have _any_ DDL privileges, and
very likely will not even have DELETE privelege on most tables, as data
will not be deleted (not by the application at least) from the database).

Now, "User" within our application is a different story. It's just a record
in one of _application_ tables, and all validation of his access rights is
done by the application itself. So, my question is - do you see anything
for concept of roles in there.

Alexey Parshin wrote:

> There is always a maximum level. We don't want any user to edit any
> other user' permisions, for instance, unless the user is a teacher of
> the course and another user is the student of the same course. There
> may be tens of objects we never want people to modify. The admin role
> is the DBO (database owner) - he has all the rights to any object.
> There may be a separate developer role for creating/modifying stored
> procs, or modifying data in any table. The table creation and table
> structure/relations should stay under control of only DBO persons, or
> small group of persons - that is critical.
> Actual course information can be controlled by the teacher of this
> course (role=teacher), and by the customer service
> (role=customer_service). A teacher' role is course-dependant. Customer
> service, however, can edit any course - to be able to fix any logical
> or security problems within any course.
> 2006/4/12, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com
> <mailto:ilya@total-knowledge.com>>:
>     Alexey Parshin wrote:
>     > Role is a maximum allowed access level.
>     Well, like I said - there is no maximum access level as such. I.E. I
>     don't see
>     any reason to have a user that can do editing of _any_ object.
>     Although
>     I do see a value in some object allowing some sort of access to
>     any user.
>     example: there can be subscriber-only course, which allows "study"
>     access
>     to set of users, and there can be public course, that allows
>     "study" access
>     to everyone.
>     > If we have a teacher, he may be also a student, but he is still
>     not admin.
>     What is "admin"?
>     > For the large mass of users, they would be just students. For the
>     > particular course, we can also determine a role for anybody. So, if
>     > the role allows - the person may make changes, for instance.
>     What do you mean? Assign role per-course?
>     > I'm pretty, that most changes would require to open screen for
>     editing
>     > an object. In this case - user gets his role from authorization
>     > routine. BTW, authorization should be done as a stored proc,
>     also. We
>     > gotta keep user information (name,pass,courses/roles) in the
>     database,
>     > anyway, and probably in some encripted format.
>     Of course - basically, every page, before being displayed will
>     have to
>     call authorization routine,
>     which will get user's permissions for this particular action for this
>     particular object.
>     > In my understanding, passing the username, pass, and a project
>     should
>     > return a role name, or an error if something isn't right.
>     >
>     --
>     Ilya A. Volynets-Evenbakh
>     Total Knowledge. CTO
>     http://www.total-knowledge.com
> --
> Alexey Parshin,
> http://www.sptk.net

Ilya A. Volynets-Evenbakh
Total Knowledge. CTO

Alexey Parshin,

Authoright © Total Knowledge: 2001-2008