I just bumped into this situation also, my case is students and employers, when I register employers I want to have "auth.settings.registration_requires_approval = True" and a different profile, but students can just register without requiring approval from admin
On Saturday, April 13, 2013 11:24:44 AM UTC-7, Anthony wrote: > > Interesting use case -- I think cases like that have come up before (i.e., > where different roles need different types of profiles). May be worth > supporting somehow, but not sure about the best approach. > > For now, you might consider putting all the profile fields in the > auth_user table, and just selectively make some readable/writable depending > on which registration/profile action is being used. Alternatively, you > could create separate tables that are simply linked to the auth_user table. > Either approach will require creating somewhat customized register and > profile actions, but that shouldn't be too difficult, and other than that, > I'm not sure there's much else to worry about. > > If you want to use separate applications, they can share a database, > though it's trickier to share model definitions (you could put them in > modules and import, or use the auto-import method) -- for more, see > http://web2py.com/books/default/chapter/29/06#Using-DAL-without-define-tables. > > I'm not sure I would create separate apps just for the sake of this Auth > issue, but if it makes sense otherwise to have separate apps, they can > share databases. > > Anthony > > On Saturday, April 13, 2013 1:53:47 PM UTC-4, David Ripplinger wrote: >> >> Okay, that makes sense. It might not be worth modifying web2py for this >> behavior when there may be a cleaner way of doing it. I had considered >> using the inherent roles and permissions, but there are several reasons why >> this would be awkward for my particular case. The main reason is that I >> overload the auth_user table with lots of data about a particular user. The >> fields I include are completely different for a regular user as opposed to >> a partner. I don't want a regular user, upon registration, to automatically >> have partner features or vice versa. In the uncommon case that someone >> wants both, I would want them to sign up for the two kinds of accounts >> separately. I also, in that case, want the ability for there to be a user >> account and a partner account both with the same email address, but I don't >> want two user (or partner) accounts to have the same email. >> >> Ideally, I would put the partners portal under a different subdomain so >> that the two aspects of the app are very much separated. For this reason, >> I'm really leaning toward running two web2py apps and giving both access to >> each other's databases and possibly expose a couple functions for them to >> communicate. But I don't know if web2py is designed to do this either. >> >> On Saturday, April 13, 2013 1:18:00 PM UTC-4, Anthony wrote: >>> >>> I think the problem is that Auth creates an object called "auth" in the >>> session, and the name of this session object is fixed. So, once someone >>> logs in with one of your Auth instances, the other instance will pull the >>> "auth" object from the session and think they are logged in with that >>> instance as well. I suppose we could add the ability to customize the name >>> of the session object to avoid this problem (though not sure there wouldn't >>> be other problems with this approach). Anyway, this is exactly what the >>> roles and permissions aspects of the Auth system are designed to address. >>> Why not just create "user" and "partner" roles and use >>> @auth.requires_membership(...)? >>> >>> Anthony >>> >>> On Saturday, April 13, 2013 12:32:36 PM UTC-4, David Ripplinger wrote: >>>> >>>> In my project, it makes a lot of sense to have two separate databases: >>>> one for the users of the app and another for partners who pay to advertise >>>> to those users. The data they manipulate are completely different sets. I >>>> have created an auth object (named auth) for the users database (called >>>> db) >>>> and another auth object (named authp) for the partners database (called >>>> dbp). I want all users stuff to be under the url myapp/default and all >>>> partners stuff to be under the url myapp/partners. >>>> >>>> The problem is that the app is mixing the two types of user accounts >>>> together in two ways: >>>> >>>> 1. If I create a user account and a partner account with the same >>>> credentials, then signing into one allows access to the pages >>>> restricted by >>>> the other (and yes, I changed the decorators to @authp instead of @auth >>>> for >>>> the partners pages). This is especially bad without email verification >>>> (which I have not implemented yet), since someone can register as a >>>> partner >>>> under the same email as an already existing regular user but with a >>>> different password. This would allow someone else to hack the user's >>>> account. >>>> 2. All the redirects are messed up. Usually, after registering or >>>> signing in, unless the URL specifies a different redirect explicitly, >>>> things always redirect back to the user account and never to the >>>> partner >>>> account page. >>>> >>>> How should I be handling this properly? Any tips for having two very >>>> different types of users are much appreciated. >>>> >>>> An alternative I would be happy with is actually making two separate >>>> apps, but I'm not sure how to exchange some database information between >>>> them. Can one app access the database of another app? Does it matter if >>>> I'm >>>> currently using sqlite? >>>> >>> -- --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
