Thanks, Graham. We'll keep using this method and I'll continue this thread if we run into problems.
I appreciate the insight re: Python's implementation of thread locals. I tend to agree re: security -- thread locals only appears to be a security threat if a system has already been seriously compromised, at which point there'd be easier attacks to execute. Kieran On May 31, 9:17 pm, Graham Dumpleton <graham.dumple...@gmail.com> wrote: > On Jun 1, 1:04 pm, Kieran Farr <kieran.f...@gmail.com> wrote: > > > > > > > We're adapting our Django powered video site to be an open video > > platform for any user to create their own "site" using subdomains (eg > > mysite.vidplatform.com) on one Django server instance. Each "site" > > would obviously have content associated with only that site in > > addition to template and navigation customizations. > > > Adapting the ``django-multisite`` app seems best and is working well > > on our dev server:http://github.com/shestera/django-multisite > > > However, a number of Django developers have expressed concerns using > > thread-locals:http://code.djangoproject.com/wiki/CookBookThreadlocalsAndUser > > > I don't see any other option besides using thread-locals to > > dynamically update SITE_ID per request. > > > What would be another way of accomplishing this goal without thread- > > locals if indeed this is not best practice? > > Irrespective of whether you use thread locals, in a multithreaded > system you are going to have that risk of one thread in your web > server potentially accessing or modifying the current state of another > thread in the system. That is simply the nature of multithreaded > systems and more so with Python where one can access just about > anything of the environment of the executing Python process, including > the stack frames of other executing threads. > > If anything I would say that thread locals if used correctly are going > to be more secure than you having your own global dictionary which is > caching information keyed on the request or thread ID. This is because > in modern Python versions it would be much harder to actually get > access to the thread local instance for another thread. This is > because the thread local object is actually kept in C data structures > for the current thread and you only get given back the object instance > relevant to variable for your specific thread. To get access to that > for another thread you may require a C extension module which > traverses all the C thread state objects for other threads. > > So, not sure why that warning has been given. I could understand it > for older Python versions where one may have been using Python > implementation of threading locals, ie., the threading_locals module, > as in that case data for other threads was exposed, but for latest > Python versions believe it is a bit harder to get at thread locals for > another thread. If this is not the case and it is easy to get at > thread locals for another thread, can someone post Python code as to > how. > > Note that someone can take advantage of this presupposes that someone > has managed to inject code into your application from outside and have > it executed. If they can do that you probably have bigger problems to > contend with than this. What for example is there to stop someone > looking at DJANGO_SETTINGS_MODULE to work out name of settings module > and then getting that module and working out what your database > password is. They could even simply access the database using active > database handle and make arbitrary queries/changes to the database, > including stuff related to users personal details. > > So, I would say that if someone has got as far as to being able to > even attempt to take advantage of it, ie., compromised your system and > can perform code injection, you are already stuffed in many many ways > and this is going to be the least of your concerns and that there is > likely much easier ways of stealing data. > > Graham -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
