In my situation, I'm offering two completely different services to my two types of users: one is getting budgeting software and the other is getting advertising options. So in my case, I have decided that it makes sense to have two separate applications placed under two separate URLs. However, I haven't gotten around to implementing it yet.
If your two types of users have some overlap in functionality, this might not be the best approach for you. You may want to consider adding an attribute similar to "registration_requires_approval" that is dependent on the auth_group, and then use the built in auth_group mechanism to differentiate between the two types of users. Since I'm not an expert in web2py yet, I'm not sure the best way to go about doing this or if it is even the best approach, but I hope it helps. On Sun, Aug 18, 2013 at 7:25 PM, dave <arifu...@gmail.com> wrote: > I just bumped into the same situation, can you tell me which route you > took? did you decide to have two applications or the other way? > > > On Saturday, April 13, 2013 10:53:47 AM UTC-7, 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 a topic in the > Google Groups "web2py-users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/web2py/vNnbYvxV81U/unsubscribe. > > To unsubscribe from this group and all its topics, send an email to > web2py+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- --- 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 web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
