+-------[ Dario Lopez-Kästen ]---------------------- | | > You just have to munge the roles into a list before returning out of the | > authSource though. | | Hm... that'd be my next ask here at work. I am planning on building a new | Generic SQL auth method that let's you specify what roles there are for a | user using a one to many relationship model (actually a many to many | relationship model). Yes the current pgAuth is a fairly naive implementation, but still serves about 95% of population. The rest probably have the skills to build their own, which is the point of it really d8) It's also probably base/apex, there should be a roles table that maps a role to a user, rather than storing a list of roles with each user. You can't easily delete a role from the system (not that this would be a common operation), and have the changes propogate cleanly. The problem is keeping it simple enough out of the box, that relative newcomers can use it. Trying to explain even more than simple schemas can be somewhat difficult at times. People understand having one table with everything in it almost immediately. I have toyed with the idea of also having pluggable Roles sources, since some (especially remote) AuthAdapters can't natively provide this, and so there's a gross hack in things like etcAuthSource where roles are stored as a private property of the user. Whilst this is great for showing off the flexibility, it still leaves a bad taste in my mouth when I think about it. | Also I want to break out the PostgreSQL dependencies, especially in the | prop_source where both the field names and the table name are hardcoded in | the python code. Having a better schema probably wouldn't hurt here either d;) -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | | ACN: 082 081 472 ABN: 83 082 081 472 | M:+61 416 022 411 | Carpe Daemon PO Box 837 Indooroopilly QLD 4068 |akm@theinternet.com.au|