Question

(this isn’t duplicate of “Changing Django settings variable dynamically based on request for multiple site”, as that previous question covers making much more serious reconfiguration at runtime)

I use sites.Site to tie content to domains/host in my project (via foreign key). Choosing appropriate Site based on request.META['HTTP_HOST'] takes place in my custom middleware.

However, I’m aware that such use of sites framework isn’t exactly The Canonical Way (I have one instance of application serving different data for different domains, while sites – AFAIK – was designed to work with several instances, one per each domain).

Element that bothers me the most is settings.SITE_ID – static setting that ties current instance of application with one Site (domain). This is used in several places, i.e. contrib.auth (to compose full, absolute url in password reset email).
So, it would be cool to dynamically change SITE_ID based on request.META['HTTP_HOST'].

So my question is:

Is changing SITE_ID dynamically (i.e. in middleware) considered a good idea?

Documentation states that altering settings at runtime is generally bad idea (here), but perhaps doing it in this case (in middleware called early enough) is fine.

(edit):

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

Answer 1

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

Specifically, any well-written apps should now be using the get_current_site function from django.contrib.sites.models. When the sites app isn’t installed, this function will just return an instance of a RequestSite object (not a model) which works similarly to a standard Site instance.

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