Opened 17 years ago

Closed 17 years ago

Last modified 14 years ago

#5022 closed Uncategorized (wontfix)

Proposed middleware: SubdomainURLsMiddleware

Reported by: tzellman@… Owned by: nobody
Component: Uncategorized Version: dev
Severity: Normal Keywords: enhancement proposal subdomain domain urlconf
Cc: drackett@… Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I'm developing an application and want to support subdomains. What I had in mind was the ability to support different views depending on the subdomain hit. Essentially, what it comes down to is I want the ability to support separate URL configurations (and thus views) for certain subdomains (known ahead of time). For example, I may have a mobile.mysite.com, where the 'mobile' subdomain deals with urls/views meant for mobile phones.

I noticed issue #4438, and it wasn't exactly what I wanted, or the right solution, so I started researching.

I noticed that in BaseHandler::get_response it attempts to get the 'urlconf' attribute from the request. So, I created a middleware that figures out the subdomain (some code borrowed from http://www.rossp.org/blog/2007/apr/28/using-subdomains-django/), and matches it against a subdomain->urlconf dictionary in settings.py. And voila! It works! Attached is the file that with the proposed solution.

I am open for critiques/discussion of this topic.

Thanks,
Tom Zellman

Attachments (2)

middleware.py (1.1 KB ) - added by tzellman@… 17 years ago.
SubdomainURLsMiddleware
middleware.2.py (823 bytes ) - added by tzellman@… 17 years ago.
updated -- it asumes your Site domain is just the base (e.g. mysite.com)

Download all attachments as: .zip

Change History (10)

by tzellman@…, 17 years ago

Attachment: middleware.py added

SubdomainURLsMiddleware

comment:1 by anonymous, 17 years ago

Example of what you'd change in settings.py:

MIDDLEWARE_CLASSES = (
    'django.middleware.common.CommonMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.middleware.doc.XViewMiddleware',
    'mysite.myapp.middleware.SubdomainURLsMiddleware'
)

DOMAINS_URLCONF = {
    'mobile' : 'mysite.mobile_urls',
    'companyA : 'mysite.companyA_urls',
}

comment:2 by Max Battcher <me@…>, 17 years ago

I appreciate this as a workable solution in some cases, but I don't think it is general enough. This doesn't easily address cases where many/all of the subdomains are sharing a single URLCONF, particularly a deeply nested URLCONF, and yet still need to differentiate content. It also doesn't provide anything in the way of support for standard contrib apps like Flatpages, as there would be no way to have different flatpages appearing on different subdomains solely by modifying the URLCONF.

comment:3 by tzellman@…, 17 years ago

Yeah, I agree with you Max. For domains that have at least some overlapping url/view mappings, this solution would require duplication, which is not ideal. This solution satisfies only a small percentage of subdomain needs out there, thus making it not generic enough. However, I think such a "recipe", for lack of a better term, could be useful to some. I guess I'm not actually expecting this to become part of the Django API, but rather wanted to get the discussion started up again, to see if we could draft up a generic solution. I would be more than willing to be a part of such an effort.

by tzellman@…, 17 years ago

Attachment: middleware.2.py added

updated -- it asumes your Site domain is just the base (e.g. mysite.com)

comment:4 by Herbert Poul <herbert.poul@…>, 17 years ago

fyi - i have done something similar for my project http://sct.sphene.net/
but the middleware would also support regular expressions to define urlconfs .. a config would look like:

SPH_HOST_MIDDLEWARE_URLCONF_MAP = {
  r'^(P<groupName>\w+)\.sphene\.net': { 'urlconf': 'sphurlconfs.community_urls', }
}

all named arguments of the regular expression are then put into a thread local so it can be used by views to further distinguish between the domains. you can see the implementation at http://yourhell.com/svn/root/django/communitytools/trunk/sphenecoll/sphene/community/middleware.py ('MultiHostMiddleware')

(i'm using 'Groups' which are similar to the concept of the 'Sites' object in django as they are used to build different sites with different configuration for my wiki and forum apps) - if something like this would be put into django the flatpages application could be easily rewritten to use a thread local to retrieve the current Site object instead of using the settings.

comment:5 by anonymous, 17 years ago

Cc: drackett@… added

in reply to:  description comment:6 by Chris Beaven, 17 years ago

Triage Stage: UnreviewedDesign decision needed

Replying to tzellman@gmail.com:

I noticed issue #4438, and it wasn't exactly what I wanted, or the right solution, so I started researching.

Note that I've put a new ticket up in #4438 which handles the issue a lot better.

comment:7 by Jacob, 17 years ago

Resolution: wontfix
Status: newclosed

A bit too special-purpose for inclusion in Django, but a good candidate for djangosnippets.org.

comment:8 by ben@…, 14 years ago

Easy pickings: unset
Severity: Normal
Type: Uncategorized
Note: See TracTickets for help on using tickets.
Back to Top