I'm a newbie to the django framework and trying to make a watchlist for stocks. I've already made the crux of the webapp, where-in, a user can search for a quote and add it to their watchlist, along with relevant data about that quote.
What I want to do now is, to save the separate watchlists that different users are creating (after creating an account on my site) and upon logging in to my site, they can view their personalized watchlist and edit it.
I'm using a model for storing the data for the watchlist quotes and looking for a way to provide the different personalized watchlists depending upon the logged in user.
Can anyone give me a lead on how to employ the logic for this? Do I need to use two data bases - one for the data of the users and the other one for storing the respective user watchlists? If yes, how do I connect everything?
EDIT: Ever used a stock investment app? The way every user/customer can log in to their account and make/edit and save their watchlists in the app - that is the functionality I want to implement. How/Where do I store so many watchlists?
use 'request.user' from your view, to know the user who sent the request and return the corresponding watchlist
Related
I'm trying to build a Django website that will be maintained and used by university students mainly. I need to restrict access to a few pages for certain approved students, but it would be very unmaintainable if I needed to create a new Django user for every student that wants to log in. Luckily, the university provides an API to check whether a username/password combination is correct. So I had the idea to create an authentication model complementary to Django's model, where users' university account can get approved by an admin, after which it is a valid login to view certain pages.
So essentially, some users may use a Django account (if they're in charge for the content of the website), and other users may just log in to view some pages with their uni account. For the uni account, the minimum amount of info should be stored (in other words, only the username is really required to approve certain users).
I can't seem to figure out how to build such a system in Django. I cannot use the standard User object because it stores data that is completely redundant, and I cannot substitute the user model because that would only make things incredibly complex. It seems reasonable to forget the User model altogether, but Authenticate needs to return a valid user. This makes me wonder, can I create regular Django users with as little information filled in as possible (dummy data except for the username), and then authenticate them with the API? Probably, but that hardly seems like a good idea.
To authenticate users using the university API, all you need to do is to write an authentication backend. You can then create a local user for these uni users the first time they login, since there is only two required fields: username and password. You can use set_unusable_password() so check_password() for this user will never return True.
The Django admin system is tightly coupled to the Django User object
described at the beginning of this document. For now, the best way to
deal with this is to create a Django User object for each user that
exists for your backend (e.g., in your LDAP directory, your external
SQL database, etc.) You can either write a script to do this in
advance, or your authenticate method can do it the first time a user
logs in.
Using Django 1.5 here. I have an application I've created that currently has one big set of data, for one "account" if you will. Meaning all the data in all the models in my application are available to all logged-in users. Now, I want to be able to allow more people to use my application but with their own set of data. So I need to separate users into different accounts with different sets of data for each account. There could potentially be one or multiple users that has access to each account. At this time I don't need different users within one account to have different levels of access though I do intend for one user to be the account "owner".
I know that to make this conversion, I of course need to add a field to every model with a foreign key to a new "account" model. But beyond that I'm a little foggy. This appears to be a square peg in the round hole of Django's auth system. So the question is, what is the best approach?
A few thoughts I had so far:
Simply filter each and every query by account
Wrap each and every view with a decorator, but with multiple models, do I have to create a different decorator for each model? Can I tell from within the decorator which model is being accessed?
Somehow make use of the Auth system's user_passes_test decorator, but again, different models.
Extend the auth system to include a request.account attribute
Create a new mixin for my views? What if I'm not using exclusively CBVs?
Different middleware?
I considered using a new group for each account and then filtering by group instead of a new account model but I predict that would be a poor fit in this situation, as it isn't using groups as they were intended.
This is less of a code question and more of a big-picture, best-practices question. How would you approach this?
What you request is not so exotic: This is called authority data - you seperate your users to authorities and each authority will have each own data. For instance, you may have a number of departments in an organization - the data of each department can be edited only by members of the same department. I have already written a blog post with a simple approach to that using django:
http://spapas.github.io/2013/11/05/django-authoritiy-data/
To recap the post, I propose just adding an Authority model for which your User will have a ForeignKey (each User will have a Profile).
Now, all your Models whose data will belong to specific Authorities will just contain a ForeignKey to Authority. To check for the permissions you could use CBVs - the django admin will only be available to the central Administrators that have access to all the data. I recommend against using the django permissions for authorization of Authority data. If you want read the post which is much more detailed and ask here any questions.
For example:
I have a user that wants to create a contact form for their personal website. They want three input type=text and one textarea and they specify a label and an name/id for them on my site. Then they can use this form on their site, but I will handle it on mine?
Is it possible for django to spit out custom forms specified by the user?
Edit: If django is too "locked down" what would you recommend I do? I would like to stay with python.
something like http://code.google.com/p/django-forms-builder or one of the million similar addins?
(made into answer at OP's request)
For this you would have some kind of editor that would create a html string. This string would be stored into your database and then upon request you would display it on the user's site.
The editor should be very strict into what it can add and what the user has control over, there are some javascript editors available that will be able to provide this functionality.
The only issue I can think of is that you may run into django escaping the form when displayed to the page.
I'm building a web application where I have 2 sets of users (students and teachers). Teachers should be able to create their account, create a page of their content. Students should be able to create an account to sign up for this content. I am currently using django-registration to handle registration but I am wondering what's the best way to handle these 2 sets of users and still be able to use the Django authentication framework? I have heard about having multiple profiles but would like some opinions.
Thanks!
You could use permissions. When they sign up if they're a Teacher give them content creation permissions. If they're a student they don't get the permissions.
In the user profile I would just have a field that says which type they are. Unless a lot of the data is different I wouldn't have two user profiles.
I'm working on a user based, social networking type of web application in Django. It's my first one so I would like to make sure I'm using some good practices.
Currently the web app supports two kinds of users. This is represented by two different Groups. When I register a user I assign them to one of these two groups. I also have two apps, one for each type of user. The apps handle whatever things are distinct to a particular type of user. I have another app that handles the actual authentication. This app uses Django's built in User type and assigns them a UserProfile. The two different types of users have their own profiles which extend/inherit from UserProfile.
This works reasonably well, and is fairly reusable since the authentication app can pull the user type from the url and figure out which type of user to create. Since the groups are named conveniently, they can be added to the correct group too.
Is this the best way or are there more preferred, tried and true ways to handle this? It seems like a pretty common enough scenario. I don't want to continue incorrectly reinventing the wheel if I don't have to.
I was thinking of adding another app called, common, or something which would handle things that are common to all users. For example, viewing a users profile page might be something anyone who is logged in might want to do, regardless of what type of user they are.
Thanks!
Easy part first, with 2) you're spot on. That would be the simplest and most effective way of doing that. It makes sense instead of replicating functionality across both applications to have one app that handles things that are common to both user types.
Back to 1)
With both profiles extending from UserProfile, you'd run into the issue of (if you were using get_profile() on a User object - see http://docs.djangoproject.com/en/dev/topics/auth/#storing-additional-information-about-users) that you'd get back just a UserProfile object, not knowing which group the user actually belongs to based on the object received. This is because they both extend UserProfile but UserProfile would not be able to be (I believe) abstract, because you want every User to have a pointer to a UserProfile object which may actually be a UserGroup1 or a UserGroup2 object.
What I would suggest you do is make two seperate Models, that do not extend from the same Model (out of necessity): Group1 and Group2. You would store the information that is common to both profiles in the UserProfile of the User object. Then in the UserProfile you would have a ForeignKey to both a Group1 and a Group2 object:
group1 = models.ForeignKey(Group1, blank=True, null=True)
You would have to do the logic checking yourself, to ensure that only one is ever valid (you could just do this in an overridden save() method or something), but then to grab all of a user's data at once, and also know which group they are on you could do the following:
User.objects.filter(username='blahblah').select_related('profile', 'profile__group1', 'profile__group2')
Only one query to the database would give you all the information you'd need about a user, and you'd also know which group they are in (the one that isn't 'None').
I hope that helps.
P.S. I am assuming in this that groups don't just have unique data to each other, but also unique functionality.