You can create a new login_method while keeping the auth tables as usual. The login method will work on the legacy db. The auth table will contain user data in another db, can be sqlite or anything else supported by DAL. Indeed web2py auth tables *do not need to contain secrets*, those can be kept on the legacy db. This is pretty much how all login_methods that delegate authentication to third parties work.
If you have more than one application to be managed that way in can be useful to create an authenticator application that does all the work of connecting to the legacy db and do proper authentication, and provide authorization (groups or whatever) info back to the consumer. The other applications can be CAS consumers to the authenticator, the CAS producer, application. mic 2012/5/11 Massimo Di Pierro <massimo.dipie...@gmail.com>: > True. gluon/contrib/login_methods only work with auth. > > > On Thursday, 10 May 2012 22:19:46 UTC-5, w2padawan wrote: >> >> so, I think they can't use auth.methods without defining auth tables first >> (kind of obvious?) >> >> 2012/5/10 Massimo Di Pierro <massimo.dipie...@gmail.com> >>> >>> In the scaffolding app there is a file db.py which defines for you >>> everything you need for RBAC. If you do not want to use this built-in >>> functionality simply delete the file and use your own API. There is nothing >>> that really depends on it. >>> >>> On Thursday, 10 May 2012 08:17:35 UTC-5, BoleroDan wrote: >>>> >>>> We're looking to use Web2py as our framework for developing a couple >>>> applications. However we already have a massive database for our research >>>> project, and almost all of the information is integrated into this database >>>> (including usernames, passwords, group names etc) so it would be nice to >>>> have web2py just access this database for username/password/group >>>> membership >>>> authentication. >>>> >>>> I'm hoping this can be integrated into Web2Pys already existing RBAC >>>> management as that would be nice. I also noticed that a lot of the other >>>> alternative login methods still require web2pys local auth_user table and >>>> stores the remote credentials locally in this table. Is this needed by >>>> design or can this be skipped? I'm just thinking its not needed for us to >>>> have duplicate login information across two databases. I just need Web2py >>>> to >>>> query our database, get the credentials authenticated and what group they >>>> are in (so i can control access to functions on web2py based on their >>>> group). >>>> >>>> Thanks for any heads up on the matter. >> >> >
