Django 하위 도메인의 구현
4386 단어 django
Django에서subdomain:Contrib의Sites App & Middleware 동적 지정request를 실현할 수 있는 두 가지 방법이 있습니다.urlconf.
먼저 Sites 가 어떠한 Domain을 정의할 수 있는지 살펴보겠습니다.우리는 모든 항목의 설정 파일settings를 알고 있습니다.py는 모두 하나의 속성 SITEID(기본값 1), INSTALLEDAPPS에도 기본적으로'django'가 포함되어 있습니다.contrib.'sites'는 그럼django 내부에서 이 앱을 사용하고 있다는 것을 의미한다.그렇다면 Sites는 우리 상부 애플리케이션에 어떤 경우에 적용됩니까?Django 문서에는 "Use it if your single Django installation powers more than one site and you need to differentiate between those sites in some way"라고 적혀 있습니다.singleDjangoinstallation에 대해 제 이해는 서로 다른site가 같은default 데이터베이스를 사용하는 것입니다. 즉, 같은django 를 사용하는 것입니다.site 데이터베이스 테이블어떻게 보면, 우리의 요구에 부합되잖아: 우리는 원래 같은 데이터베이스에 있는데, 다른site만 설정하면id면 됩니다.하지만 사이트id는 settings에 설정되어 있습니다. 이것은 서로 다른 사이트가 서로 다른 프로젝트를 필요로 한다는 것을 의미합니다.이것은 일부 서로 다른 사이트 간의 기능 관련이 긴밀하지 않고 기존의 구조가 명확하며 다시 사용할 수 있는 앱이 있는 프로젝트에 있어 큰 문제가 되지 않을 수 있다. 그러나subdoamin이 그 기능 논리 코드와 밀접한 관계를 가지고sites의 방식으로 처리하는 것은 너무 난폭해 보인다.
두 번째 방식을 보십시오:middleware가 지정한 Request.urlconf 속성.Django는 Request를 두 부분으로 전달합니다.1. request.path_info, 요청한 URL입니다.2. request.urlconf, 프로젝트 처리의 모든 URL입니다.middleware에서 우리는 urlconf를 특정한 urls로 지정할 수 있습니다.py, 지정되지 않으면 settings의 ROOT 를 기본적으로 사용합니다URLCONF.urlresolvers에서 Resolve와reverse 방법을 호출하면 Request의urlconf 속성을 지정할 수 있지만 안타깝게도template의 url 라벨이urlconf 속성을 드러내지 않았습니다.
생각해 보면 우리는 서로 다른subdomain에 자신의urlconf(귀찮지 않고 유연한urlpatterns구조에 귀결된다)를 정의하고middleware에서domain의 정보에 따라 정의된subdomain에 전송하면 목적을 달성할 수 있다.
그렇다면 이런 실현 방식에 무슨 문제가 있을까?1. runserver 시 ROOT 제거URLCONF가 정의한 patterns입니다. 다른 도메인 이름의 URL을 사용할 수 없습니다.runserver에서 IP를 통해 접근했기 때문에 Domain 정보가 없습니다.2. Django의reverse에domain 정보가 없기 때문에 우리는reverse의 결과를 대응하는subdomain에 수동으로 지정해야 한다.
이 두 문제를 해결하기 위해서 우리는 Trick을 사용했다.우리는middleware 처리를 할 때subdomain의 정보를 보존하고 path에 반영하도록 합니다.urls에 있습니다.py에서 대응하는patterns 구성하기;마지막으로reverse에서subdomain의 정보를 추출하여 정확한 URL을 구성합니다.코드는 다음과 같습니다.
SubdomainMiddleware:
class SubdomainMiddleware(object):
def process_request(self, request):
domain_parts = request.get_host().split('.')
if len(domain_parts) == 3:
# subdomain URI
request.path_info = '/%s%s' % (domain_parts[0], request.path)
return None MIDDLEWARE에 추가CLASSES에서 위쪽 위치를 확인합니다.여기에서, 우리는 Request를 수정하지 않았습니다.path의 정보는 pathinfo야말로 Django 내부 발송의 근거이며, 동시에 우리는 우리의 수요에 따라 path 또는 path 를 유연하게 인용할 수 있습니다info.
Reverse Monkey Patch:
# not in settings.py: will be imported twice
# not in urls.py: too late
# works in models.py
from django.conf import settings
if not settings.DEBUG:
from django.core import urlresolvers
def reverse_subdomain(*args, **kwargs):
path_info = old_reverse(*args, **kwargs)
parts = path_info[1:].split('/', 1)
path_info = 'http://%s%s/%s' % (
parts[0], settings.SESSION_COOKIE_DOMAIN, parts[1])
return path_info
old_reverse = urlresolvers.reverse
urlresolvers.reverse = reverse_subdomain 여기에 우리와 우리가 사용하고자 하는 제3자 패키지는reverse의 결과에 의존하지 않고 이를 더 이상 처리하지 않고 페이지에 표시하거나 방향을 바꾸는 등 직접적으로 되돌아오는 행위일 뿐이라는 가설이 있다.이 가설은 우리가 기본적으로 성립되었다고 느낀다.
그리고 하나 더 설명해야 할 것은,re를 포함한다.VERBOSE (\x) 나 0 너비 단언의 정규 표현식은 Resolver일 때는 문제가 없지만, Reverse일 때는 'Non-reversible reg-exp portion' 이기 때문에 이상합니다.때때로 우리는 효율을 위해 고려할 수도 있고, 자신의 호기심과 도전욕을 만족시키기 위해 복잡한 정규가 일치하는 것을 쓰기 위해서일 수도 있으며, 왕왕 필요없는 것이다.
#출처: 구구단 블로그
웨이보에서 주목: 시나닷컴, 텐센트 투고
모집
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
Django의 질문 및 답변 웹사이트환영 친구, 이것은 우리의 새로운 블로그입니다. 이 블로그에서는 , 과 같은 Question-n-Answer 웹사이트를 만들고 있습니다. 이 웹사이트는 회원가입 및 로그인이 가능합니다. 로그인 후 사용자는 사용자의 ...
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
CC BY-SA 2.5, CC BY-SA 3.0 및 CC BY-SA 4.0에 따라 라이센스가 부여됩니다.
좋은 웹페이지 즐겨찾기
