cache Django pour les sous-domaines

Question

J'utilise sous-domaines dans django pour les pages de l'utilisateur via un ce middleware pirater d'une manière similaire à décrit here:

Maintenant, j'ai le cache de django par défaut activée pour toutes les pages pour les utilisateurs non connectés. J'ai dû désactiver implicitement le cache pour les pages utilisateur car il traitait ces pages comme si elles étaient les pages /, par exemple. filmaster.com et michuk.filmaster.com est la même page que django. Connaissez-vous un moyen simple et facile de forcer django à comprendre les sous-domaines pour la mise en cache? Ou suggérez-vous que je cache juste chacune des vues de sous-domaine explicitement?

Mise à jour: réellement examiné dans ce solution et ce n'est pas exactement comment nous le faisons. Nous ne redirigeons pas. Nous voulons que l'URL reste dans le sous-domaine, donc ce que nous faisons est d'appeler directement les vues depuis le middleware.

Vous pouvez voir les détails de la mise en œuvre hacky ici: musielak.eu/public/film20/film20/core/middleware.py [Mise à jour: 404 page non trouvée] (utilisateur: justlookingaround, passer: le film @ ster - oui, nous sommes open source). Et voici un jira pour réparer le hack: jira.filmaster.org/browse/FLM-54 (mais ce n'est pas tout à fait pertinent au problème - c'est juste pour s'assurer que vous ne pensez pas que nous supportons le codage merdique: P)

Answer 1

OK, voici une solution que nous avons effectivement utilisé . Cela implique malheureusement de pirater le code Django, en particulier la méthode _generate_cache_header_key dans django/trunk/django/utils/cache.py Ce que nous faisons est simplement de vérifier s'il y a un sous-domaine dans l'hôte HTTP et si oui, d'en extraire le sous-domaine et l'ajouter à la clé de cache. Nous pourrions aussi simplement ajouter l'hôte, ce qui fonctionnerait de la même manière, mais en prenant quelques bits plus précieux en RAM.

Voici le jira: http://jira.filmaster.org/browse/FLM-84 Et voici le code utilisé. À utiliser à vos risques et périls!

def _generate_cache_header_key(key_prefix, request): 
    """ 
     Returns a cache key for the header cache. 
     With Filmaster hack for handling subdomain caching: http://jira.filmaster.org/browse/FLM-84 
    """ 
    subdomain = None 
    path = request.path 

    # TODO: this is not a decent implementation, it will work only on domains with one dot it them 
    # To fix it, we'd need to pass a param to the request object before CacheMiddleware 
    # this current domain name in it, and use that domain name in the regexp below 
    m = re.match(r"([^\.]+)\.[^\.]+\.[^\.]+", request.META['HTTP_HOST']) 
    if m!=None: 
     subdomain = m.group(1) 

    if subdomain != None: 
     path = subdomain + "___" + path 
    path = md5_constructor(iri_to_uri(path)) 
    return 'views.decorators.cache.cache_header.%s.%s' % (key_prefix, path.hexdigest()) 

Answer 2

Malheureusement, je ne peux pas résoudre votre problème principal (mettre en cache les sous-domaines), sauf pour dire que tout ce que j'ai lu implique que Django ne peut pas gérer cela de manière élégante. C'est possible que cela a changé pour la version 1.1, mais si c'est le cas, je n'ai rien trouvé à ce sujet. Dans mon application particulière, je ne peux pas mettre en cache les sous-domaines de toute façon, donc je n'ai pas examiné quelles modifications internes pourraient être nécessaires pour améliorer ce travail.

Cependant, en ce qui concerne la manière d'accéder à des vues de sous-domaine, une autre option que vous pourriez envisager quelque chose comme ceci:

class SubdomainMiddleware: 
    """ 
    Make the company specified by the subdomain available to views for 
    appropriate processing. 
    """ 
    def process_request(self, request): 
     """ 
     Populate a company attribute on the request object with the company 
     indicated by the requested subdomain. 
     """ 
     domain_parts = request.get_host().split('.') 

     if (len(domain_parts) > 2): 
      subdomain = domain_parts[0] 

      if (subdomain.lower() == 'www'): 
       subdomain = '' 
     else: 
      subdomain = '' 

     if subdomain != '': 
      try: 
       request.company = Company.objects.get(subdomain=subdomain) 
      except Company.DoesNotExist: 
       return HttpResponseRedirect(''.join(['http://test.com', reverse('findcompany')]))     
     else: 
      request.company = None 

Je pense que cela est assez explicite - c'est une version fortement modifiée de quelque chose que je trouvé sur djangosnippets. Il analyse simplement le sous-domaine, le recherche dans la table de la société et, s'il s'agit d'une société valide, il est ajouté à l'objet de requête pour être géré par la vue. De cette façon, si test.com/test et sub.test.com/test sont tous deux valides, la vue peut contenir cette logique, plutôt que de la pousser dans le middleware. En outre, les sous-domaines de déchets sont facilement transmis à une URL de recherche.

j'avais l'intention de comparer à votre middleware (plus pour ma propre éducation que toute autre chose), mais l'URL que vous avez fourni votre code renvoie une 404.