Two databases with an auth in each

[David Ripplinger]

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?

[Anthony]

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

[David Ripplinger]

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.

[Anthony]

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

[dave]

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

[dave]

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?

[David Ripplinger]

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.

--
 
---
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+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[dave]

Thank you very much for your response

[Annet]

>  Alternatively, you could create separate tables that are simply linked to the auth_user table.

This is what I did, and so far it works out well. I followed the 'party' pattern and added the
party.id to the auth_user table.


Kind regards,

Annet