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.
