Django Microservices - skip all user created tables for non-user services - django

I am using Django in a Microservice architecture. I already have a userService for authentication with JWT with an apiGatewayService that checks if token is valid before routing requests to other services. This means that I do not need all the standard tables that are created for a user (user tokens, sessions, email etc) in my other services when I run python manage.py migrate.
Is there a way to opt out of creating these unnecessary tables?
I have read some people just saying not to run migrations so as not to create these tables, but I obviously want to create other tables (say I have an ordersService, I want an orders table etc).

If you don't want that functionality at all, then remove the relevant apps from INSTALLED_APPS.

Related

Django transfer database to different Django project without messing up the logic

I built a Django project with a few models. Now I created a second server with the same setup. This one is meant to be the deployment server. Databases are separate from the dev-server.
However can you tell me if I can simply copy the databases from the dev server to the deploy or will the Django logic, since I also mean the user models and permissions etc.
The tables which I created myself are no problem to transfer to the new server. However I am wondering If Django gets confused when I also transfer something like the auth_user Model.
Should this work since I also just copied the backend logic as well?

Django should I manage users in a separate django-app?

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.

Migrate users from database to another on Django

I already have an existing website running and want to transfer just the users (usernames, passwords and emails) to another database for a separate Django website as I am rebuilding it.
You can configure both databases in your django configuration file. select the user data from one database and then put the records in the other.
Multiple Databases in Django.
Moving an object from one database to another

Using .csv as user model in Django

I have a django app that works with .csv files as database, in these files i have the users of the system (i can't change that), i need to implement security (a login) in the site. Any idea?
Your question is very vague and you didn't ask for specifics so here is a general overview of what you'll need to do.
If you intend to use django's built-in authentication system then you'll have to setup a database; even if its sqlite. Once you have setup a database, run manage.py syncdb to create the necessary authentication tables (by default, the settings.py that django creates is already setup for the authentication system, so you don't have to make any other changes).
Once you have that done, you'll have to write a fixture to load the users from the csv file into the authentication tables. You can read up on that in the documentation under providing initial data for models.
Now you are ready to set passwords and permissions. Your next task will be to make sure that the csv file is in sync with the authentication tables if there a change in the csv file.

Different authentication backend for the django admin

What would be the best solution to use a different authentication backend for the Django admin site?
See the documentation, which contains this quote:
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.