Dynamic Subdomain Generation for Users

[vemo...@gmail.com]

Hi guys.

I'm developing a system that gives a user a sub domain for their
account.

I found this article, http://www.rossp.org/blog/2007/apr/28/using-subdomains-django/,
which is really helping. But the problem I'm having trouble thinking
through is how I could give sub domains certain urls that the main
domain wouldn't have. For example:

A user's account would be user.domain.com. When they access that it
would redirect to user.domain.com/login. I don't want the normal
domain.com to be able to go to /login without being a sub domain.

Ideas on how I should implement this would be great.

Thanks,
Levi

[Bruno Tikami]

Hi vemon,

when the user access user.domain.com the request will be treated by a different project or all users share the same project? Though it may look a stupid question, if they have separate projects, you don't have to worry about it, cause they'll have different urls.py files.

If they share the same project, I can't help you. BTW, I don't even now how to share the same project with several sub-domains (using apache).

Regards,
Tkm

--
[]s!

Tkm
http://djangopeople.net/brunotikami/

[vemo...@gmail.com]

Hey Tkm,

Basically this application follows the Basecamp model. A company signs
up for a sub domain, and many users are able to access it. It would be
all in one project, but the sub domain would access a different url.py
so that different applications and views can be used.

Let me know if that helps,

Levi

On Mar 31, 4:02 pm, "Bruno Tikami" <brunotik...@gmail.com> wrote:
> Hi vemon,
>
> when the user access user.domain.com the request will be treated by a
> different project or all users share the same project? Though it may look a
> stupid question, if they have separate projects, you don't have to worry
> about it, cause they'll have different urls.py files.
>
> If they share the same project, I can't help you. BTW, I don't even now how
> to share the same project with several sub-domains (using apache).
>
> Regards,
> Tkm
>

> On Mon, Mar 31, 2008 at 5:39 PM, vemon...@gmail.com <vemon...@gmail.com>

[Dan Ellis]

Hi, Levi. I've just had a look through the code, and it appears you're
in luck (at least in the trunk -- I haven't looked elsewhere). core/
handlers/base.py contains this line[1]:

# Get urlconf from request object, if available. Otherwise use
default
urlconf = getattr(request, "urlconf", settings.ROOT_URLCONF)

It would appear that if the request contains an attribute called
'urlconf', that will be used instead of the default urls.py. So all
you need is a request middleware[2] that examines
request.META["HTTP_HOST"] and sets the appropriate urlconf.

Bah. On closer inspection of the docs, it appears this is already
documented[3]. Still, it was a satisfying search ;-)

Hope this helps,
Dan

[1] http://code.djangoproject.com/browser/django/trunk/django/core/handlers/base.py#L68
[2] http://www.djangoproject.com/documentation/middleware/#process-request
[3] http://www.djangoproject.com/documentation/url_dispatch/#how-django-processes-a-request

[vemo...@gmail.com]

Thanks, Dan!

Just what I needed.

On Mar 31, 5:58 pm, Dan Ellis <d...@remember.this.name> wrote:
> Hi, Levi. I've just had a look through the code, and it appears you're
> in luck (at least in the trunk -- I haven't looked elsewhere). core/
> handlers/base.py contains this line[1]:
>
>     # Get urlconf from request object, if available.  Otherwise use
> default
>     urlconf = getattr(request, "urlconf", settings.ROOT_URLCONF)
>
> It would appear that if the request contains an attribute called
> 'urlconf', that will be used instead of the default urls.py. So all
> you need is a request middleware[2] that examines
> request.META["HTTP_HOST"] and sets the appropriate urlconf.
>
> Bah. On closer inspection of the docs, it appears this is already
> documented[3]. Still, it was a satisfying search ;-)
>
> Hope this helps,
> Dan
>

> [1]http://code.djangoproject.com/browser/django/trunk/django/core/handle...
> [2]http://www.djangoproject.com/documentation/middleware/#process-request
> [3]http://www.djangoproject.com/documentation/url_dispatch/#how-django-p...

[Sarah...@student.griffith.edu.au]

Hey,

 

I am currently looking at installing multiple instances of Django on a server to use Django as a teaching and learning tool.

 

What is the best way to go about this?

 

I want to minimise the amount of storage needed and optimize the performance of the server.

 

I have heard that modwsgi can be used to specify different ports for each instance.

 

I was a little concerned about using the same db for all the students, as if they make a bogus query, update or insert on the db the whole db could be altered unfavourably.

 

Could the script used in this post be used to create subdomains for the users? Has this script has been written for just one instance of django?

 

Is the easiest way going to be to create a directory for each user where a new instance of django is installed?

 

Any help or advice would be greatly appreciated.

 

Thanks,

 

Sarah

 

Research Computing Services
Griffith University, Nathan QLD
0402241794

[Graham Dumpleton]

On Apr 1, 1:21 pm, Sarah.Va...@student.griffith.edu.au wrote:
> Hey,
>
> I am currently looking at installing multiple instances of Django on a server to use Django as a teaching and learning tool.
>
> What is the best way to go about this?
>
> I want to minimise the amount of storage needed and optimize the performance of the server.

I wouldn't get too worried about performance, at least not speed. You
would probably find Django's internal development web server more than
adequate in a teaching environment and certainly would make restarts
when code changes easier to manage.

The only time internal server may be a problem is if writing complex
AJAX applications that expect to be able to have multiple concurrent
requests handled while prior requests haven't been completed. This
would be an issue because internal server is single threaded and
wouldn't allow concurrent requests which overlap in time. In other
words, all requests are serialised.

Only other real issue is the amount of memory used and as long as you
stick with Django development server, or use a hosting mechanism which
uses a single multithreaded process or non threaded this shouldn't be
a problem either. Use a multithreaded process though and you have to
start introducing students to issues of thread safety in programming.

People who do have problems with too much memory being used are often
trying to run Django embedded inside of Apache prefork processes on a
memory constrained VPS. In other words, you just need to pick the
right hosting technology. You also need to consider whether in the
time of the course whether students would develop enough stuff that it
would start consuming huge amounts of memory.

> I have heard that modwsgi can be used to specify different ports for each instance.

Technically, no it doesn't. There seems to be growing misunderstanding
in some quarters about how mod_wsgi works and this is one of the
misconceptions. The other main misconceptions are that mod_wsgi
implements some sort of wire protocol called WSGI and that the
'python' executable is actually launched as a separate process to run
the application. Neither of these is correct either.

What mod_wsgi does is implement the WSGI functional API specification.
This is to do with what happens within a Python process and how a web
server layer talks to a higher application layer. It has got nothing
to do with socket communications, its is a programmatic interface
only.

That all said, mod_wsgi does conceptually allow what you want in as
much as it does allow instances of applications to be run in separate
processes if you enable that feature. Those processes are though a
direct fork of the Apache parent process. Communications between these
processes and main Apache child processes is handled by UNIX sockets,
but that is actually totally irrelevant as the socket isn't the
defined public interface as it is with something like FASTCGI. Even
when run in the separate process the interface is still the
programmatic WSGI interface, mod_wsgi just handles it all
transparently and makes it work.

> I was a little concerned about using the same db for all the students, as if they make a bogus
query, update or insert on the db the whole db could be altered
unfavourably.

Again because I don't believe that performance should be your priority
in your setup, just use separate sqlite data for each user. This has
the benefit as well that you don't need to set up and manage a full
blown database system.

> Could the script used in this post be used to create subdomains for the users? Has this script has been written for just one instance of django?

If you set up each user with their own Django instance this would be
required in the first place.

> Is the easiest way going to be to create a directory for each user where a new instance of django is installed?

Pretty well. You just need to allocate them a separate listener socket
port number for them to use so they don't tread on each other though.

Anyway, all probably depends on how simple you want to keep it. :-)

Graham

> Sarah Vardy

[Sarah...@student.griffith.edu.au]

Hi Graham,

 

Thanks so much for all that information, it is greatly appreciated.

 

Kind regards,

 

Sarah vardy