multiple Auth's

[Anthony]

Should we allow multiple Auth instances in the same app (see https://groups.google.com/forum/?fromgroups=#!topic/web2py/vNnbYvxV81U)?

Minimally, I think it would require being able to specify a custom name for the auth object stored in the session (instead of hard-coding to "auth"). With only that change, you would still either have to use separate databases for each Auth or generate custom names for all the Auth tables. We could make the latter automatic by using the custom session name as the default prefix for all the tables (e.g., of the custom session name is "authp" instead of "auth", then the table names could default to "authp_user", "authp_membership", etc.). Would this be sufficient to allow multiple Auth's, or is there something I'm not thinking about?

Anthony

[Niphlod]

well, from a theoretical standpoint, all the code should be searched by instances of session.auth: I'm assuming there are a lot of places with the value hardcoded

a few examples: the signature check in html.py, permission checking in the grid, wiki too, and of course all the internals of auth needs to be checked closely

Plugins also needs to be rewritten, as they assume there's a fixed auth object available....

for what is worth, having two separate instance for a small usecase seems hard to maintain.

[Anthony]

Yeah, I'm not sure it's worth it either. I don't think plugins would have to be re-written, though -- the idea would be that the default instantiation of Auth would be exactly the same (i.e., it would still use session.auth, db.auth_user, etc.). Anyway, it might be nice to more easily support the case where different roles/groups need different profile fields.

Anthony

[Niphlod]

well, I'm not familiar with the usecase as described in the thread, but I have an app where there are 3 distinct roles, and I added a "user_type" field to the auth_user table.
Everyone is in the same auth_user table, noone can register with the same email, so there aren't "collision" problems.

Every action that is reserved to each type has a simple decorator on top

@auth.requires(auth.user and auth.user.user_type == 'thegroup')

As for managing different profile data, I just replaced the profile function with an external table that stores all the data and switch on/off readable and writable attributes based on the user type (I was a newbie then).
Attaching on the login event I simply go to that table and store in the session.something the "profile" data.
onlogout I clear the session.something