Question

I am rewriting a legacy application that has a database for each customer. Each customer has its own authentication and user set. Thus, I’ll need a custom authentication backend because django’s auth is set to only use default. I have written middleware that examines the url upon every request and extracts information there to set a database_name on the request.

If I had access to the request during processing of my custom authencation backend, I could easily perform database calls as user = User.objects.using(request.db).get(username=username) However, I see no easy way to accomplish this. I’ve seen an answer to that here: Access request.session from backend.get_user, but this wouldn’t appear to be thread safe so I don’t want to go down that road.

The only solution I can see that still uses django-auth is to have an authentication backend for each customer that sets the database name to be used as a class attribute. Then, I would create a custom login function that sets the request.session[‘_auth_user_backend’] to be the customer specific backend. Thus, when get_user(user_id) is called on each request, it uses the customer backend which knows which database to request from.

I would like to avoid having to manage an authentication backend for each customer if possible. Is there a better way to do this?

Answer 1

Since the auth backend is not calling the QuerySet method using you could use a database router with a thread local variable and some middleware to set the variable to the customer’s database name. The middleware would have to be placed before the authentication middleware.

The thread local variable is thread safe. It creates a thread local global variable.

If you were following the path of a request it would do the following:

1. The request hits django
2. Your custom middleware grabs the database name from the url sets it to the thread local global variable.

3. The django authentication middleware starts and sets the user by running the query User.object.get(id=user_id). This will use your database router which will just return the thread local global variable that was set in the previous middleware.

4. The request continues into the rest of the django stack.

For example you have the following modules:

my_app/middleware.py

from threading import local

my_local_global = local()

class CustomerMiddleware(object):
    def process_request(self, request):
        my_local_global.database_name = get_database_name(request)

my_app/routers.py

from middleware import my_local_global

class MultiCustomerRouter(object):
    def db_for_read(self, model, **hints):
        return my_local_global.database_name

settings.py

...
MIDDLEWARE_CLASSES = (
 'django.middleware.common.CommonMiddleware',
 'django.contrib.sessions.middleware.SessionMiddleware',
 'django.middleware.csrf.CsrfViewMiddleware',
 'my_app.middleware.CustomerMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 'django.contrib.messages.middleware.MessageMiddleware',
)

DATABASE_ROUTERS = ['my_app.routers.MultiCustomerRouter']
...