2

ここで説明されているのと同様の方法で、ミドルウェア ハックを介してユーザー ページに django のサブドメインを使用しています。

これで、ログインしていないユーザーのすべてのページでデフォルトの django キャッシュが有効になりました。ユーザーページのキャッシュを暗黙的に無効にする必要がありました。これは、それらのページを / ページであるかのように処理したためです。たとえば、filmmaster.com と michuk.filmmaster.com は django と同じページです。

キャッシングのために django にサブドメインを強制的に理解させる簡単で便利な方法を知っていますか? それとも、各サブドメイン ビューを明示的にキャッシュすることをお勧めしますか?

更新：実際にそのソリューションを調べましたが、それは私たちがそれを行う方法とは正確ではありません. リダイレクトしません。URL をサブドメインのままにしたいので、ミドルウェアから直接ビューを呼び出すだけです。

ハッキングされた実装の詳細は、musielak.eu/public/film20/film20/core/middleware.py [更新: 404 ページが見つかりません] (user: justlookaround, pass:film@ster -- yes, we'再オープンソース)。そして、ここにハックを修正するための jira があります: jira.filmmaster.org/browse/FLM-54 (しかし、それは問題に完全に関連しているわけではありません - それは、私たちがくだらないコーディングをサポートしていると思わないことを確認するためです :P)

4

2 に答える 2

0

OK、これが実際に使用した修正です。残念ながら、Django コード、特に django/trunk/django/utils/cache.py の _generate_cache_header_key メソッドをハッキングする必要があります。HTTP ホストにサブドメインが存在するかどうかを確認し、存在する場合はそこからサブドメインを抽出し、それをキャッシュキーに追加します。単純にホストを追加することもできます。これはほとんど同じように機能しますが、RAM の貴重なビットをさらに使用します。

jira は次のとおりです: http://jira.filmmaster.org/browse/FLM-84 そして、使用されたコードは次のとおりです。自己責任！

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())
于 2009-09-01T22:22:14.637 に答える
0

残念ながら、あなたの主な問題 (サブドメインのキャッシュ) に対処することはできませんが、私が読んだすべてのことは、Django がこれを洗練された方法で処理できないことを暗示していると言うだけです。これはバージョン 1.1 で変更された可能性がありますが、そうであれば、私はそれについて何も知りませんでした。私の特定のアプリケーションでは、とにかくサブドメインをキャッシュすることはできないため、これをより適切に機能させるために必要な内部変更については調べていません。

ただし、サブドメイン ビューにアクセスする方法に関しては、次のような別のオプションを検討することをお勧めします。

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

これはかなり自明だと思います.djangosnippetsで見つけたものを大幅に変更したものです. サブドメインを解析し、それを company テーブルで検索し、それが有効な会社である場合は、ビューで処理するためにリクエスト オブジェクトに追加されます。このように、test.com/test と sub.test.com/test の両方が有効な場合、ビューはミドルウェアにプッシュするのではなく、そのロジックを含めることができます。また、不要なサブドメインは簡単に検索 URL に渡されます。

私はこれをあなたのミドルウェアと比較するつもりでした (何よりも私自身の教育のためです) が、あなたがコードに提供した URL は 404 を返します.

于 2009-07-01T15:35:05.597 に答える