There are two points that we have to consider: 1) there is also a role model that is present in lift 2) how would we integrate the idea of authorization groups if we had access to ldap (my favored solution) (http://jgoday.wordpress.com/2009/11/27/lift-ldap/) - although here the problem may the association with MegaProtoUser
The use of the superuser is probably the easiest way to get started with such an api but the two other means above are probably better in the long-term. By the way, if we had a ldap solution, then we might have to rethink our pool administration, but first things first. ... D. On Sat, Dec 19, 2009 at 8:08 PM, Ethan Jewett <[email protected]> wrote: > Sounds ideal as long as someone familiar with the user model (not me > :-) can confirm that this column is being used in this manner. > > If it's not being used at all at the moment, then I could start > building admin functions on top of it, but we'll find ourselves in a > situation in which you can do things through the API that you can't do > through the ui. > > There are also the questions of how the first super-user is added and > whether we want more granular access controls around administrative > functions. The later is probably a question for the future. > > Ethan > > On Saturday, December 19, 2009, Richard Hirsch <[email protected]> wrote: >> Just saw the column "superuser" in the "users" table. >> >> Maybe this could be used to determine if user have special rights >> during administrative functions for our APIs. >> >> D. >> >
