UniverseUniversity


Home Projects Jobs Clientele Contact

uu


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

Re: UU Database



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>:
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

Authoright © Total Knowledge: 2001-2008