On Mar 29, 8:43 am, hambaloney <[EMAIL PROTECTED]> wrote: > Hello! > > I'm hoping to get an idea on how to approach a system setup I've been > thinking about. > > In this system: > - a group of users each has it's own Django site and database. (e.g. > Group A has access only to Site A, etc) > - each Django site shares common application code. > - all users log in via a common portal and are 'redirected' to their > respective sites (I'm using contrib.admin in my example, so they're > redirected to their admin) > > Ideally, this common portal would be seamless to the user. They log in > and immediately see their admin. > > Couple of questions: > > 1. Is it possible to set up a portal in such away that the user login > information can be then used to authenticate them against their site? > I suspect I'd have to duplicate user entries, e.g. UserA would be in > the portal db as well as SiteA db. Ideally I'd want one interface to > manage all users, so redundant entries doesn't appeal. > > 2. Can I make this seamless? I would like users to use example.com, > login, and then, with the same url, utilize their site. I'm currently > using Apache+mod_python, but I have full access to a test server so > anything is possible. I was looking through Apache modules and read > through the proxying docs. Basically I can imagine hosting each Django > instance separately, via Lighttpd or another Apache instance, and > proxying, but the way I understand proxying, its a mapped address > (e.g. /myuser -> 127.0.0.1:someport), but I'd rather not have the / > myuser url. > > If any of this is unclear, let me know.
If I understand what you want to do, I somewhat doubt you could do this with a single instance of Apache running mod_python, or would be quite hard. This is because the only way to separate Django instances in mod_python is by running them in distinct interpreters. Problem there is that which URLs go to which interpreter instance with mod_python is static and would be able to be dynamically changed based on the identity of the user. You may however be able to do this with mod_wsgi. I would not though use separate interpreters for each Django instance however, but us mod_wsgi daemon mode to run them all in a separate process. There are then various means in mod_wsgi of dynamically delegating specific requests to a particular process and the Django instance in that process. This could be determined from a cookie or Basic auth credentials. Problem at that point though is how for a single top level URL for application to have DJANGO_SETTINGS_MODULE be calculated differently. The issue here is that Django uses an environment variable to set it and thus to have that somehow dynamically set through the WSGI application environment variables passed by mod_wsgi as directed by Apache configuration files and some rewrite rules is a bit of a hack. It isn't that it can't be done, as Django uses that sort of hack with mod_python to allow it to be set in Apache configuration. Thus, the separation bit is probably achievable with mod_wsgi as would be the dynamic delegation. The bit I was unsure about was how you wanted to work the front portal. I sort of know how that could be done as well, and it would require the duplication of credentials as you say, unless you use some sort of custom auth plugin for Django that allow sharing of user database. Anyway, I'd suggest you have a look at mod_wsgi and if you are happy with running Django under mod_wsgi to begin with, then we can work out how to do the rest. At that point, may make more sense to take the discussion over to the mod_wsgi discussion group on Google groups. Graham --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
