I'm creating a Django website that supports both local login backend and LDAP login (through django-auth-ldap), and maybe more in the future.
I'm getting into Django login and backends sutff and have a couple of questions - mainly is there any reason Django doesn't keep user creation backend in the database? Shouldn't user A be linked (and by linked I mean a field on User model) with the backend django.contrib.auth.backends.ModelBackend for safety/convince reason?
I'm getting around to creating a custom user model, and was thinking about adding such field. The ability to unambiguously know which backend was/is used to create/login the user sounds logically for me, but the fact that Django doesn't have that by default, and that I can't find anything similar on the Internet has me worried that I didn't think of a really good reason for why it's done the way it is.
Thanks in advance,
Paweł
Django doesn't need that info. Once the user is authenticated, and django has a User model, it doesn't care what backend authenticated it. The User model data is stored in one source. The User model (whether the default or custom) is consistent and has the same attributes, functionality and behaviour across the entire django project and schema. Nothing in the out-of-the-box django deals with different user models.
You may extend this with AbstractBaseUser, but managing really different users across the same project, especially with the core django modules, is a strech.
Django uses the User model a lot, and you will have to manually locate each place it does, and provide your own router to the correct backend. There is no API for this (like, say, db routers), it's going to be a mess of hacks that will probably even messier with each upgrade.
Django does support, in addition to the custom user model, "authentication backends". Some of the functionality your are looking for is available and exposed with this option, in a formal API. So you probably want to stick with that.
see:https://docs.djangoproject.com/en/1.9/topics/auth/customizing/#authentication-backends
Related
So I'm starting a new Django project that essentially requires the login & registration process be routed through an EXTERNAL & ALREADY created database.
Is it possible to have the User model use an EXTERNAL database table ONLY when Django is:
Logging in a user, to check if the login is valid
Registering a user, inserting data for that user in the external database
I would like for the rest of the Django server to use a local database.
If so, could someone either provide examples or guide me to documentation on the subject?
Easiest way to use multiple database with Django is to use a database routing. By default Django stick to single database, however, if you want to implement more interesting database routing system, you can define and install your own database routers.
Database routers are installed using the DATABASE_ROUTERS setting. You have to specify this setting in your settings.py file
What you have to do is write one AuthRouter as described Django documentation Django Multiple Database
"Yes, but"
What you are looking for in the docs is called "database router".
There is even an example for the auth app in the docs there.
But, there is s serious drawback to consider with this approach:
We cannot have cross-database relationships in the models. If auth tables are in a separate database, this means that any otehr app that needs a foreign key to User model is going to run into problems. You might be able to "fake" the relationships using a db that doesn't enforce relationship checks (SQLite or MyISAM/MySQL).
Out of the box, such apps are: session, authtoken, and admin (and probably more).
Alternatively, a single-sign-on solution might do a better job: django-sso, or django-mama-cas + django-cas-ng, or the commercial Stormpath.
I've created a custom user model (AbstractBaseUser) so that user could login into my website.
The problem is that I want to keep using Django's default user and authentication system for the admin so that staff could easily log in and manage stuff.
I saw a lot of tutorials but all of the instruct to change the setting AUTH_USER_MODEL, but if I change that I won't be able to keep using Django's default user.
Is there any solution for this?
Thanks in advance.
I have never implemented this myself, but to point you in the right direction, it may be worth having a read through this:
https://docs.djangoproject.com/en/1.10/topics/auth/customizing/#authentication-backends
By the sounds of things you may be able to write an authentication backend for your front end user model, that you can run in tandem with Django's authentication system.
If you could get this to work, I would imagine that you would then have to make sure that the front end user model, once authenticated, can not access the admin part of the site.
For me the million dollar question here is, why do you want to keep the front end and backend users on separate models? They both have the same job, to authenticate the user?
I've created several projects in the past where there are front end users and admin users. Out of the box, without any modification you set the user attribute is_staff=False for front end users and is_staff=True for the admin users; that determines whether or not a user can access the admin part of the site, and I've never had any issues with this approach.
If the front end user (or backend user) desires additional functionality, the simplest solution would be to extend the user model:
https://docs.djangoproject.com/en/1.10/topics/auth/customizing/#extending-the-existing-user-model
Alternatively you could user your could create a custom user model and use this for both.
If you're willing to provide more details, perhaps I could help further, but unless there's a strong reason for having separate user models, I'd just stick with the one and configure and extend as you need.
I hope this helps.
I am about to start designing a multitenant CRM solution.
The interesting libraries that appear are
the list of libraries that can be used are - https://dpaste.de/vvzWw/ (you can suggest edits if you wish as to which libraries would be better for a multi tenant django crm soln)
Now my major question is every instance(tenant) of the crm will have admin.
The django admin provides an awesome admin interface, I want the admin to be able to perform only contact/user management feature from the admin interface, and nothing else, that too only the users that belong to his sub-domain.
Can this be achieved or will I have to design a separate interface for the tenant admin?
YMMV but my own experience is that django-admin is a PITA to customize beyond simple things, and that I get better results writing a custom interface when the users needs are anything more than simple low-level CRUD (and don't get me wrong, django-admin is really great).
Now restricting which ModelAdmins are available to a given user and restricting the ModelAdmins querysets according to the current user is definitly not a problem in django-admin so if that's all you need you can always start that way and only start writing your own admin interface when you find the domain requires something more complex / specialized than what django-admin provides.
I am new to django and have gotten a bit stuck on trying to make the admin site work as I'd like it to. I am wondering if for making the admin functionality I want it is better to make a custom admin app with a template inheriting from admin/base_site.html, using the frontend login with a redirect when is_staff is true.
The initial details that make me think this:
I have a chain of foreignkeys and would like to display nested inlines on the parent admin page. I have tried using easymode, but it's got its own issues and requirements that may cause headaches later i can do without.
I would like to add a function allowing the admin to add an instance of a model, which triggers the creation of instances its related models and redirects etc. This requires adding some callables at least, which I havent figured out yet how to really do with any success in the admin model, and at the moment seems easier to just quickly do this in the views.py of my own app rather than trying to toy with the admin views.
In general, creating a custom admin app (using a is_staff=true redirect on the FrontEnd login) seems more flexible in the long run, and will result in a more designed and intuitive admin interface for the client - so I suppose my question is, what are the semi-pros doing? (if you know how to hack the admin views and templates to your heart's content you are not a semi-pro :) )
Thanks for any advice you can offer, Im still getting my feet wet and this kind of advice could save me alot of time and headache.
Slow down. Relax. Follow the Django philosophy.
You have an "app". It presents data. Focus on presentation.
You have a default, built-in admin for your "app". It updates data and it's already there.
If the admin app doesn't meet your needs update Forms and update Models to get close. But don't strain yourself messing with admin. Get as close as you can. But relax about it.
[Also, "more intuitive admin" is sometimes not an accurate description of what you're trying to do. It could be, but I've seen some "more intuitive" that actually wasn't.]
a more designed and intuitive admin interface for the client.
Is this part of the app? Does the app do more than simply present data?
If the app is transactional -- add, change, delete -- crud rules -- that kind of thing, then that's your app. If you want a fancy UI, that's not admin any more. There's no redirect. That's your app.
It's just coding. Stop messing with admin and start writing your app.
Hint: Use generic views as much as possible.
Other than that, you're talking about your app, not hacking the admin stuff that already works.
if you know how to hack the admin views and templates to your heart's content you are not a semi-pro
Wrong. All the source is there. You can read it, also. That's what the pros do. We read the source. And we don't hack the admin app.
If you have complex transactions, you have a first-class, for-real, actual application. Not default admin, but a part of your app that has forms.
If you have forms, then, well, you have forms. This does not require hacking the admin app, it's just coding more of your app.
Go through the links mentioned in this post as well. This may be helpful for you.
Is Django admin difficult to customize?
I am writing a Django app, and I would like an account to be created on our Google Apps hosted email using the Provisioning API whenever an account is created locally.
I would solely use signals, but since I would like the passwords to be synchronized across sites, I have monkeypatched User.objects.create_user and User.set_password using wrappers to create Google accounts and update passwords respectively.
Monkeypatching seems to be frowned upon, so I would to know, is there a better way to accomplish this?
Have you considered subclassing the User model? This may create a different set of problems, and is only available with newer releases (not sure when the change went in, I'm on trunk).
Subclassing seems the best route, as long as you can change all of your code to use the new class. I think that's supported in the latest release of Django.
Monkeypatching is definitely bad. Hard to say anything since you've given so little code/information. But I assume you have the password in cleartext at some point (in a view, in a form) so why not sync manually then?
I subclass User with Django 1.0.2. You basically makes another table that links to the user_id.
class User(MyBaseModel):
user = models.OneToOneField(User, help_text="The django created User object")
and then at runtime
#login_required
def add(request) :
u = request.user.get_profile()
You can then easily overwrite the needed methods.
And for those that hadn't heard of monkeypatching : http://en.wikipedia.org/wiki/Monkey_patch. It is a derivation from guerrilla patch.