The overall use case is that I want to lookup the correct Business for an authenticated User at the start of each view function so that I can look up relevant info for the appropriate Business.
In my app, an User can only be mapped to one Business, and a Business can map to many Users. To create this mapping, I would like to put a foreign key for a Business in the User model. The Django documentation I've read states that creating a custom User model, which this would require, is not necessary for most applications.
Having such a mapping of an User to something else seems like a pretty common use case, so I'm wondering if there is a simpler way to do this that I'm not aware of.
One approach I thought of would be to have a BusinessUserMapping model, which would contain foreign keys to both Businesses and Users. I could then do a lookup of a BusinessUserMapping where the User foreign key matches the current User, but this seems somewhat convoluted.
Any advice on a better way to look up a Business based on the User?
Related
I just started fidling with the user model, and I'm probably wrong on this but I just had a thought and I'm not knowledgable enough to persuade myself it is indeed wrong.
I have a user model, which I extended with a profile via a one-to-one model. (most sources I could find recommended this as a best practice).
Now, it is possible for general users on my app to access bits of the profile data, such as someone's username (part of the user model) or nationality (part of the profile model).
I grab this data in a view I created via objects.get and pass on the results to a template. But doesn't this also pass on the (hashed) passwords? And if so isn't this unsafe?
No. Why would passing the user model to the template be unsafe? End users don't have control of the template, only your code does. If you don't use the password in the template anywhere, then the end user will not have access to it.
In any case, even if you did use it, as you point out only the hashed password is present; but a hash itself is useless. To log a user in, Django needs a raw password which hashes to the same value; but hashes are not easily reversible, which is the whole point of using them.
I am using mongo connector.
I have a offers model which has a hasMany relation with my Users model via interested_users key. Basically the idea is that an user can mark an offer as interested or not_interested, and I need to exclude the not_interested offers. What is the best/efficient way to achieve this?
I am still not sure I fully understand your issue, but it is definitely related to querying data with loopback REST API, and especially where filter
If your model offer has a property someone_is_interested (boolean), then the following request could work for you
GET /api/offers/?filter[where][someone_is_interested]=true
But I have the feeling you want to use the relation to store all users that are interested in an offer. In this case, simply establish the relation between any interested user and the offer with this request (in the database, one instance of offer with id=1, and a user with id=2:
PUT /api/offers/1/interested_users/rel/2
And to remove the relation (just the relation, not the user or offer)
DELETE /api/offers/1/interested_users/rel/2
Then, you can simply query all related users of offer with id=1, which will give you all interested users on that offer
GET /api/offers/1/interested_users
I am designing a Django application (v1.6) and need to do several things with users:
Add custom fields, such as a foreign key for user department
Trigger database changes when certain fields change. For example, when the user's department changes I need to move inventory in another model out of the old department and into the new. I was planning to use a pre_save receiver to do this.
Define custom permissions, such as a user can only modify rows in a table that are associated with their department.
Eventually I want to integrate the application with our Active Directory server for authentication.
I looked at the options in the documentation and see that there are several options, from extending the user model with a one-to-one relationship to writing a custom user model.
What design should I use to meet all of the above goals?
Take a look at this blog post: it provides all the design principles to achieve your goals.
http://www.roguelynn.com/words/django-custom-user-models/
I would also take a look here for more information about Configurable User Models, if you want to have your own authentication scheme:
http://procrastinatingdev.com/django/using-configurable-user-models-in-django-1-5/
I also found the following reference helpful: http://www.sofokus.com/blogi/custom-user-model/
I'm currently developing a Django site in which users can have multiple 'accounts', so that they can seamlessly switch between different public profiles when interacting through the site. What I'm designing is likely to attract multiple registrations per person (and won't be discouraged), I just would like to offer this in such a way as that users can keep the profiles tied together, switch easily and only have to log in once.
The two approaches I've thought up so far include:
One (User model + SiteProfile model) pair and many PublicProfile models per person. AUTH_PROFILE_MODULE is set to point to the SiteProfile model. Issue with this is that I can't easily use per-object permissions: these will be set on the User object and not the public profile, thus permissions to see a page for "PublicProfileA" will also be applied to when the user is masquerading as "PublicProfileB".
One Account model and many (User model + UserProfile model) pairs per person. AUTH_PROFILE_MODULE is set to point to the UserProfile model. This would have the added benefit of the permissions working as intended, and that I can simply have a Custom Backend that will switch users by authenticating a user by if they are currently logged in as another user that has the same Account object as the Foreign Key. Authentication would happen by reading fields on the Account object though, which would mean the password field on every User object would be wasted.
As above, but subclassing Account from User. I've been advised strongly against this though (for reasons unclear).
Is there any pitfalls or better approaches to this? Ultimately, should I use the built-in User model as the one-per-person model that identifies a group of public facing profiles (of which these profiles have a FK back to the User object), or use it as the profile itself, linking back to a single Account object for each person?
Yes, I think the best approach would be to have one and only one User per person and several PublicProfile objects that they can "switch" between. This gives the benefit of only one username/password for them and seems to make the most sense with how Django's auth typically works.
I'm wondering what people's thoughts are on joining models directly to the auth.User object vs to the user's profile model.
I'm storing some different types of models which my user are adding in my app. App users will search for other users via criteria on these models.
On the one hand, I'm thinking that if I join straight to User then I won't need to do request.user.get_profile() each time I need to grab the User's records, and it doesn't presuppose that a User always has a profile (they do in my app at the mo, but still). This leaves the profile model as just containing the user's contact details.
On the other hand, I imagine I'll most likely need values from the Profile (eg name, location) when I'm looking up these other models.
No doubt either will work, so maybe it doesn't matter, but I just wondered what other people's thoughts were.
Thanks!
Ludo.
I would also recommend creating foreign-keys to the User model. It just makes your life simpler when working with the user object in the view, for one. So, you can do things like request.user.foo_set, etc. without having to go through the profile model.
In general: If you want to make your apps reusable, always create foreign keys to User model.
As you already said, in most cases you will need User as well as Profile instance, so to prevent multiple database queries, use cache.
If reusability isn't relevant, create foreign key to Profile and use select_related() to get User instance with single query.