Fixes for uninitialized thread-local SITE_ID #3
Conversation
In some cases the thread-local variable ends up being unmodified, the value will then be unpredictable as we may get one from a thread that was previously used. Instead it is always reset to the default.
…uce a new setting for this package Set the settings DOMAINS_ALLOW_DEFAULT_SITE_ID to the ID that should be the default. If the value is not set (or 0) it will not use the default site.
Picking a random site in the fallback is not necessarily a good idea. If you still want the behaviour set DOMAINS_ALLOW_FALLBACK to True.
|
Hi, Jan Did you cover your code with tests? |
|
Can you reproduce your case, please? Please tell me scenario or (it's preferred) write some unittest cases? |
|
Hi, I don't think there is an easy way to write automated tests for this as it only occurs on a production setup, I've never had the problem with my development setup. After adding several log entries to the django-domains code I was able to spot that a new request got the SITE_ID value from a previous request result. The scenario I have is a site that uses multiple sub domains, each sub-domain maps to a database object which limits the request to certain subset of private data. With the SITE_ID bug I ended up with sub-domains pointing to the wrong subset, which is quite catastrophic. |
This fixes a problem with the thread-local SITE_ID variable being unmodified in some cases.
I've had issues with requests switching between the Site instances at seemingly random, by ensuring that the SITE_ID is always properly initialized we avoid this problem.
In addition I disabled the fallback code that picks the first Site item, picking a random site is not what you normally want.
I used a setting for it so it can be brought back if wanted.