> 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-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
No comments:
Post a Comment