Is changing SITE_ID dynamically by middleware considered a good idea?

Question

(this does not duplicate "Changing Django dynamic parameters dynamically based on a request to multiple sites" , as this previous question is about a much more serious run-time reconfiguration)

I use sites.Site to bind content to domains / host in my project (via foreign key). Choosing the right Site based on request.META['HTTP_HOST'] is done in my regular middleware.

However, I know that using the sites structure is not a completely canonical way (I have one instance of an application serving different data for different domains, and sites - AFAIK - was designed to work with multiple instances, one for each domain) .

The element that bothers me the most is settings.SITE_ID - a static parameter that associates the current application instance with one Site (domain). This is used in several places, i.e. contrib.auth (to make up the full, absolute URL in the reset email password). Thus, it would be great to dynamically change the SITE_ID based on request.META['HTTP_HOST'] .

So my question is:

Changing SITE_ID dynamically (i.e. in middleware) is considered a good idea?

The documentation states that changing the settings at runtime is usually a bad idea ( here ), but maybe in this case (in the middleware called early enough). [/ p>

(edit):

It works as expected locally (Django test client), but I am considering concurrent requests in a production environment with multiple threads and / or processes.

Answer 1

Why don't you just turn off django.contrib.sites ? If you remove this from INSTALLED_APPS , you should be fine.

In particular, any well-written application should now use the get_current_site function from django.contrib.sites.models . When the site application is not installed, this function will simply return an instance of the RequestSite object (rather than a model), which works similarly to standard site instances.

To answer the original question, although editing settings dynamically is never a good idea .