Django project has two apps. Customers & Operations.
I want to separate access to the apps with separated front ends. The user authorization strategy I will follow to achieve this is where I am stuck. My research has is advising against two user models. And I recently found out about Proxy models.
I need opinions on best approach for above requirement.
the access links requirements are e.g
app1 customers.example.com
app2 operations.example.com
Customers will have its own set of users and authorization.
Operations will have its own set of users and authorization.
Operations app will create Customers[eg Cust_X, Cust_Y].
Cust_X will have users[eg User_X1, User_X2]
Cust_Y will have users[eg User_Y1, User_Y2]
Related
Let's say I have 1 Django project where I want host multiple websites on with different domains. I managed to set it up but progressing further is where I get confused.
We'll call them store1.com, store2.com
I can route to both sites through a custom middleware that checks the url where the request comes from and that is working fine.
Both stores have it's own apps like cart, category, product, account and so forth.
What would be the best practice to structure this?
Do I put everything from a store inside 1 app or is it better to have all these models and views in a separate app and keep checking the request so that the app knows which URL to serve?
IMHO the best way is to create an app for all the different functionalities and then use Django Sites framework to manage multiple sites.
You can read more on the Django documentation
I am currently at the planning stage of an app that will consist of standard
Django part for supervisors that can perform all CRUD operations on employee users mostly add, delete and view statistics - viewed in browser (no frontend framework just using Djangos server side rendering), two step email authentication on each login, session based auth
DRF part for employees - API connected to mobile app, authentication based on device ID. (no username, or password)
DRF part for clients to contact the supervisors if employees do something wrong - Token or JWT based authentication using passcode delivered by mail.
I am not used to splitting Django projects into multiple sub-projects (or using same database for different projects) but it feels like every part of the project should be a standalone app due to different authentication type and the fact of simultaniousily using DRF with standard Django
Can anyone who had similar problem or has some experience, advise what should I do considering different authentications and overall different user types in this project? What would be pros and cons of going into solo or multiple projects? Thanks in advance!
You're asking for opinions, so don't be surprised if the question gets closed, but I'll answer with facts:
A split over different projects using the same database has the following issue: shared migrations. They all use built-in users, so require some standard apps to be enabled that have migrations and they won't run on the 2nd and 3rd project.
You're going to need a custom user model to support the device id authentication method: You need information that is not on the standard user model to be available at authentication time - the number 1 reason to create a custom user model. Ties into migrations and also a synchronization hell code-wise.
Django's Authentication Backends system allows for different authentication methods to exist at the same time, so there is no need to split anything. If you're worried about security, you can always use different hostnames and the Sites framework to add an extra layer of protection, but they would still use the same code.
DRF started as an addition to Django's view-based approach, not a replacement to make part of a project's code available as an API. While current usage is more "DRF or templates" this is a result of people increasingly becoming binary ("this" or "that") and wanting to be in the cool club, but has nothing to do with technical reasons. They can and always will be able to co-exist as they solve different problems. In fact, DRF's generic views make use of Django's CBV's and the built-in browsable API makes use of templates. Also, the admin is template/view based and it's convenient to develop the app or manage data with the built-in admin.
Is there a way to deploy Django Admin and your main application separately, though both of them sharing the same Models / Business logic services.
I come from Grails background where you can create a plugin which can hold your Entities and common business logic and that plugin can be utilized by other application deployed and scaled separately though using the same Database. You don't have to repackage your plugin again for every change rather its just sibling folder to your other projects.
Can I achieve something similar with Django?
Assuming a typical setup, in order to be useful Django Admin needs access to project's apps and their models.
So a setup that you've described would require at least:
simple URLconf with just Django Admin
models and their Admin bindings for all apps that need Admin
settings with database credentials
Even if your models and Admin bindings are not dependent on other parts of the codebase,
extracting the above components to a separate project and then keeping everything
in sync sounds pretty hard.
Summarizing: I would say it's hard but possible if it's something that you really need,
but Django Admin hasn't been designed with such use case in mind.
Django admin is actually separate from the main application by placing it on its own url. Even if they know the admin url, users cannot log in to the site's admin unless they have already been assigned Staff status via the admin. You can set the admin prefix to anything you want, so if you want to "hide" the admin login page, just make it something long and random (good for security too), and basically no one but those you tell will even know where the admin site can be found.
In Django 2.2, if I plan to make authentication its own service in the future and serve requests through DRF, should I put my User model in a separate app from my regular "functional apps and models"?
There's no way each app should contain its own implementation of auth, right?
UPDATE: I ultimately plan to use Keycloak for auth so that I can easily SSO.
Project_Root
|--app_access
|--app_shipper
|--app_cleaner
Absolutely.
If you use the default Django authentication, you will notice that Permission, Group, User models are grouped together in one app.
I have written a web app in Django with usual Django project structure. At my company, they want to separate front end and backend on different servers. Frontend server will have internet access and backend will have a strong firewall and no net access. What I understand from this concept is, they want to separate back-end (view.py) from Django project to shared folder (shared with the back-end server). Is it possible to separate view.py file to the different folder and then import it to project?
Also another question on the same topic. Does Django have good security or security ideas like this are required to protect against hacking? What measures should I take to ensure protecting my backend against hacking if I can't separate backend? (I have already implemented LDAP authentication, using CSRF tokens and all pages are protected by #login_required)
What you can do is creating two projects, one for serving your "front end" with a disabled admin (simply remove the 'admin' in your project's urls.py) and another one for managing the django admin and only accessible from inside your company's network.
Make them share the same database where the database server should only be accessible from within your company's network, as well. Be sure to only create the models only in one app, preferably in the front end app as you might want to have user input handled by django forms.
Register the "front-end" app models in the "back-end" project via the admin.py in the "back end" app. That should allow you accessing the data stored in the db.
When it comes to third party apps and plugins be sure to check their urls.py (and disable the admin in case), models.py and admin.py in order to implement it in your "back-end".
Hope that helps!