I have one question about changing the site ID per request.
I assume that settings is imported from conf, and so in the end it is simply
changing the same SITE_ID to fit the current request Django is handling.
Does this ever become a problem? I am setting up around 250 sites for
example. If the site_id had a conflict because it is trying to be changed in
two places at the same time.
It is probably a dumb question, but I was wondering.
Cheers,
James Hancock
On Fri, Jan 28, 2011 at 2:54 PM, Jjdelc <jjd...@gmail.com> wrote:
> If all you need to change is the SITE_ID on the settings file, using
> different files for each is not only a mess to handle, but also means
> that you'll spend extra RAM for each instance running.
>
> I solve this by using a middleware that changes the SITE_ID based on
> the request's hostname:
>
> SITES_DICT = 'cached-sites-dict'
>
> class MultiHostMiddleware(object):
> def process_request(self, request):
> if cache.has_key(SITES_DICT):
> sites = cache.get(SITES_DICT)
> else:
> sites = {}
> for site in Site.objects.all():
> sites[site.domain.lower()] = {
> 'id': site.id,
> }
> cache.set(SITES_DICT, sites)
>
> try:
> host = request.META["HTTP_HOST"].lower().replace('www.',
> '')
> domain = urlparse(host).path
> settings.SITE_ID = sites[domain]['id']
> except KeyError:
> raise Http404()
>
> This way I only have one instance running 'hundreds' of websites.
> With this approach you can create a OneToOne model SiteOptions to
> store extra settings, like TEMPLATE_DIRS, STATIC_ROOT, or other site's
> options like API keys and such. I have an app that has the fields for
> the site I'm doing but it works fine.
>
> If you need different urlconfs, you could also do it in the middleware
> (since urls are resolved against request.urlconf which you can set
> there), but I think that at that point you're talking about another
> website so I'd use a different settings file for it.
>
>
> On Jan 27, 3:16 pm, Graham Dumpleton <graham.dumple...@gmail.com>
> wrote:
> > On Friday, January 28, 2011 2:09:06 AM UTC+11, Tom Evans wrote:
> >
> > > On Wed, Jan 26, 2011 at 6:18 PM, Jari Pennanen <jari.p...@gmail.com>
> > > wrote:
> > > > On Jan 26, 6:56 pm, FeatherDark <msens...@gmail.com> wrote:
> > > >> Greetings huge django developer list,
> > > >> I just wanted to mention, this method totally works for me, I call
> it
> > > >> "Skinning"
> >
> > > >> In the templates folder I have a file called "base.html'
> > > >> Inside that file is only 1 line:
> > > >> {% extends request.META.HTTP_HOST|cut:':'|add:'.html'%}
> >
> > > > request.META.HTTP_HOST is coming from Client. "Trust but verify", you
> > > > are not verifying this. It could pose a security risk. One could send
> > > > a request with malicious Host header and make the site retrieve
> > > > different template. This is not a serious issue, since you probably
> > > > don't have templates that would wreak havoc.
> >
> > > > Why don't you create own template context processor that would add
> the
> > > > verified HTTP_HOST to template context? Then you could do just
> >
> > > > {% extend MY_VERIFIED_HTTP_HOST %}
> >
> > > > See:
> >
> > >http://docs.djangoproject.com/en/dev/ref/request-response/#django.htt.
> ..
> >
> > >http://docs.djangoproject.com/en/dev/ref/templates/api/#writing-your-.
> ..
> >
> > > request.META['HTTP_HOST'] is also the primary mechanism for
> > > determining which website to serve when doing virtual hosting, IE if
> > > you use apache and your site is hosted in a structure like:
> >
> > > NameVirtualHost *:80
> > > <VirtualHost *:80>
> > > ServerNamewww.foo.com
> > > ServerAlias *.foo.com *.bar.com *.quuz.com
> > > ....
> > > </VirtualHost>
> >
> > > Then that variable already is being verified.
> >
> > Yes and no.
> >
> > Apache uses it to resolve name based virtual hosts, but if it cant match
> it
> > against a specific virtual host from memory it routes the request to the
> > first VirtualHost which was found in the Apache configuration for that
> port.
> >
> > Have many times seen broken VirtualHost configurations which shouldn't
> work,
> > but seem to, because the user only had one VirtualHost definition and so
> > Apache was routing the request to it anyway.
> >
> > If you were going to be rigorous you would add a dummy VirtualHost as
> first
> > in Apache configuration and have 'Deny from all' in it so that any
> attempts
> > to access unknown host would fallback to this and get forbidden.
> >
> > Graham
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com<django-developers%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
