How to modify the identity management?
Christoph Zwerschke
application using TurboGears. I'm bound to use the existing database
model and its user and access management. This is based on SQL users and
roles in the (PostgreSQL) database, i.e. users and roles created with
the SQL commands "create user" and "create role", plus some tables
providing additional access control. I'd like to tweak the identity
module to use SQL based users instead of its own user tables. Has
anybody done something like this already? How should I proceed?
Another questions: I noticed that some of the database tables used by
the identity module have names starting with tg_ which I think is a good
idea, because it is easy to distinguish them from the database tables of
the application, but some do not start with tg_. Wouldn't it be better
if all the tables start with tg_ (I know you can customize the names,
but I think it would be good to have good default names anyway).
-- Christoph
Jorge Godoy
> I'm trying to add some functionality to a legacy client/server
> application using TurboGears. I'm bound to use the existing database
> model and its user and access management. This is based on SQL users and
> roles in the (PostgreSQL) database, i.e. users and roles created with
> the SQL commands "create user" and "create role", plus some tables
> providing additional access control. I'd like to tweak the identity
> module to use SQL based users instead of its own user tables. Has
> anybody done something like this already? How should I proceed?
This would greatly enhance security on a TG application. A while ago I posted
a message where I did a really fast analisys on TG's security choices and this
feature of using roles and database security would be great. I wish I had
more time to implement that.
You can start by checking the alternative identity providers (such as the LDAP
provider) so that you know what you'll need to do. The easiest way is to
"duplicate" security and also insert some data at tg_user, IIRC. This is
needed because of the relationship with visit (again, IIRC).
> Another questions: I noticed that some of the database tables used by
> the identity module have names starting with tg_ which I think is a good
> idea, because it is easy to distinguish them from the database tables of
> the application, but some do not start with tg_. Wouldn't it be better
> if all the tables start with tg_ (I know you can customize the names,
> but I think it would be good to have good default names anyway).
I agree with you.
--
Jorge Godoy <jgo...@gmail.com>
Christoph Zwerschke
> This would greatly enhance security on a TG application. A while ago I posted
> a message where I did a really fast analisys on TG's security choices and this
> feature of using roles and database security would be great. I wish I had
> more time to implement that.
>
> You can start by checking the alternative identity providers (such as the LDAP
> provider) so that you know what you'll need to do. The easiest way is to
> "duplicate" security and also insert some data at tg_user, IIRC. This is
> needed because of the relationship with visit (again, IIRC).
I have it now running. Instead of duplicating the user and group tables,
I have modified the User and Group classes to read from pg_user and
pg_group instead of tg_user and tg_group etc. I mapped the postgresql
column names usename and usesysid to user_name and user_id etc.
(manually - it does not seem to be possible with ActiveMapper, cmiiamw).
I also had to tweak the model concerning the relation between users and
groups. Instead of creating my own permissions table, I used one that
already existed in the data model of the legacy application. And finally
I had to replace the validate_password() method with an attempt to login
with that user and password on the same database that sqlalchemy.dburi
is pointing to. Only the visit tables had to be created on the database.
By the way, the visit table is defined two times with different names in
the turbogears visit module ("tg_visit") and in model.py ("visit").
Instead of redefining the class in model.py, turbogears should simply
reference the already defined class in the visit module.
-- Christoph
Jorge Vargas
>
> Jorge Godoy wrote:
> >
>
> I have it now running. Instead of duplicating the user and group tables,
> I have modified the User and Group classes to read from pg_user and
> pg_group instead of tg_user and tg_group etc. I mapped the postgresql
> column names usename and usesysid to user_name and user_id etc.
> (manually - it does not seem to be possible with ActiveMapper, cmiiamw).
activeMapper goal is to create the obvious relations, this of course
is not there but that's why ActiveMapper is so great, it gives you
automatic stuff for simple tasks and doesn't hides SA for complex
ones.
> I also had to tweak the model concerning the relation between users and
> groups. Instead of creating my own permissions table, I used one that
> already existed in the data model of the legacy application. And finally
> I had to replace the validate_password() method with an attempt to login
> with that user and password on the same database that sqlalchemy.dburi
> is pointing to.
yes that method needs to be refactor to provide a simplier way of
checking autentication.
> Only the visit tables had to be created on the database.
>
> By the way, the visit table is defined two times with different names in
> the turbogears visit module ("tg_visit") and in model.py ("visit").
> Instead of redefining the class in model.py, turbogears should simply
> reference the already defined class in the visit module.
>
on the contrary the ones inside turbogears are deprecated, the reason
all that was moved to the model is flexibility.
> -- Christoph
>
> >
>