Jorge Godoy wrote:
> 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
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~----------~----~----~----~------~----~------~--~---
