I am creating an app where I store the USERS in a Postgres database with the help of the standard User Model, in my Django app i use Django queries to get all needed information, like "first_name", "username" .. etc
I implemented Django_auth_ldap to start storing user identification data in an Openldap server if i want. But now, i'm confused to how to get the data i used to get using django queries. i don't want to change the behavior in my views, i want to continue using Django queries
This looks like it describes some of what you want: https://django-auth-ldap.readthedocs.io/en/latest/users.html
You can perform arbitrary population of your user models by adding listeners to the Django signal: django_auth_ldap.backend.populate_user. This signal is sent after the user object has been constructed (but not necessarily saved) and any configured attribute mapping has been applied (see below). You can use this to propagate information from the LDAP directory to the user object any way you like. If you need the user object to exist in the database at this point, you can save it in your signal handler or override get_or_build_user(). In either case, the user instance will be saved automatically after the signal handlers are run.
Related
i am getting user data from a Django form which i need to validate manually and then save it to django model database, the problem is that validation might take 24-48 hours. How do i hold the data temporarily so that when validated that data can be sent to the database using django models automatically, is there any functionality in django which will allow me to do that, if not how to do it.
I would save in the database but without activating the user, it will prevent creating other users with this email address and other similar problems.
I have written one Django cloud based app. This app will have multiple user and for them multiple database, so that their data should be separate and they can save only to same database.
1) How can we implement it
2) How to automatically one user from login page to assign the database to write on it.
I don't have a complete answer, since you do not give a lot of detail. But here are a couple ots that f hinDjango supports custom database router implementations. A database router is a class that helps django decide which database to use for a particular model. Unfortunately I don't think this mechanism is granular enough for your needs. You can also specify the database to use in your code by using using(name) queryset method and save(using=name) form of save() method for instances. Of course this also means that some features of Django are going to be unvailable to you, since you cannot always expect to have a user. Look at the docs here for more info
https://docs.djangoproject.com/en/dev/topics/db/multi-db/
I implemented a django custom authentication backend. My authenticate() returns a user object like this return User(username=username, password=password), but I never store the User object to a database.
Why do do the django docs recommend creating a database with user objects? (https://docs.djangoproject.com/en/1.4/topics/auth/#writing-an-authentication-backend - "...the best way to deal with this is to create a Django User object for each user that exists for your backend...")
If I try calling login(), there's a call made to the database. If logins are stored in sessions, why is a database necessary? (Using cached sessions)
The reason why you specifically need to save the User object is that it's common for apps to create database level relationships between objects and users (in order to persist the relationship across multiple requests).
A simple example would be the activity log in django.contrib.admin. It displays recent behaviour that users have performed. This only works when the user object is saved to the database.
Quite a few apps have a foreign key to auth.User; if you don't have that table populated then you don't get to use those apps.
As the Django documentation says about Other authentication sources, in order to authenticate against another source, you must implement your own authentication backend. Also, They explain that:
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.)
As i'm not going to use the admin system (i'm assuming they are referencing the admin application) can i avoid that table replication?
I was thinking of implementing the authenticate and get_user methods as the doc says but that implies the instantiation of the User class, so the next question would be: can the auth.models.User class be instantiated without having the actual Django User table?
The short answer to your question is - yes, it can. Simply set the managed property to False on the User model.
You should map the user from the external authentication into the auth.User object.
Remove django.contrib.auth from the INSTALLED_APPS setting.
Is there a particular reason you don't want the table to be created? If you write (or use a pre-existing) LDAP authentication backend, the User objects will be stored in the table, but they won't have any password information stored, and you can easily update fields like email address and name during the authentication process, so you won't create a disconnect between information stored in LDAP and managed in the Django table (i.e., you can continue updating auth information from LDAP, and don't have to worry about also updating it in the Django DB).
There's no way to avoid the table and still have any sort authentication. The "alternative" authentication methods still make use of the auth_user table, they just authenticate via another means.
I have a Profile model that is used to define a profile for a User from the auth application. Also, I have a signal that will create an empty profile each time a user is created.
The problem is that, when starting from clean, the Profile table is created after the User table, so, when I am asked to add the super user, my signal function fails, because there is no Profile table to enter the empty profile.
Is there a way to force in which order the tables should be created by the syncdb, so that the profile table should already be created when the super user is added ?
Do one of the following:
Modify your signal to catch this specific error (table does not exist) and ignore it. Won't help if you need to have Profile for superuser too.
Do not insert any data before whole DB schema is initialized. You don't have to create superuser during syncdb, this can be done later from dev console (django-admin.py shell) or you could put superuser's User and Profile to your app's initial_data.json fixture that is loaded automatically during syncdb. This will reset it's information on ever syncdb, but in certain cases it's acceptable.
Use AutoOneToOneField from django-annoying lib to automatically create Profile the first time it's accessed. This is how I'd solve this problem myself -- no need to redo existing functionality with signals. Here's an example from their wiki:
from annoying.fields import AutoOneToOneField
class MyProfile(models.Model):
user = AutoOneToOneField(User, primary_key=True)
The order in which the tables are created depends on the order in which you have them in your INSTALLED_APPS
Try moving your app with Profile above django.contrib.auth
Unless you are using a database with Foreign Key checks, in which case the User table may need to be first.