UniverseUniversity


Home Projects Jobs Clientele Contact

uu


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

Re: UU Database



Role is a maximum allowed access level. If we have a teacher, he may be also a student, but he is still not 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. 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.
In my understanding, passing the username, pass, and a project should return a role name, or an error if something isn't right.

2006/4/12, Ilya A. Volynets-Evenbakh < ilya@total-knowledge.com>:
OK. So we are clear on the fact that application will provide access
control.
Now on to "roles" - one thing that should be understood is that we don't
have
application-wide roles. i.e. I can be course creator/author for course
X, but
will be a student for course Y. Furthermore - there is even more
granularity:
we have a concept of shared objects (most of things can be shared between
courses in fact). I.E. I can create a problem, that will be reused by
multiple
courses, or an explanation. I'm not sure about whole topics yet, but
probably
they can be shared as well. Thus an author may not have edit rights to all
of objects within his course. So, where does the concept of role fit in this
picture?

Alexey Parshin wrote:

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


--
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com




--
Alexey Parshin,
http://www.sptk.net

Authoright © Total Knowledge: 2001-2008