On Wed, 2008-11-26 at 20:17 -0800, Brian wrote: [...] > The situation is this: I'm creating a web-site with a bunch of > accounts - each account having its own database. I want people to go > to the site (i.e. www.example.com/) and when they log in the > application gets all its requests/responses from their account's > database. For the moment, all accounts will be using the same Django > applications, though that is subject to change so I'd prefer not to > rely on a solution that precludes that possibility.
Whilst I'm all in favour of attempting to solve problems given arbitrary constraints as a thought exercise, I think this one isn't really the best practical solution to anything. You are proposing having a single addressable URL that points to vastly different content based on some other, transparent piece of information (a cookie). Why not use the URL space as it's been designed and give each instance its own URL? We have the domain namespace for that at the topmost level, as well as the full URL namespace for subdivisions at a different layer: www.example.com/user1/ and www.example.com/user2/ , for example. You can do the authentication checks as an addendum to that, for example at the indivdual lighttpd (or other webserver of choice) level. I'll go so far as to claim that your proposed setup up breaks the web. Not a single request to that site will be effectively long-term cacheable, since they will all have to vary on cookie. And you're using the same resource name for an arbitrarily large number of difference resources. The web performance and behaviour of people using such a setup is actively harmed when it's so easily avoidable. If you really, really wanted to go down the one name to rule them all path (for example, it wins you a really large bet that you accepted by accident), you could use mod_rewrite to do an internal redirect to the individually named URLs (maybe combined with some other modules). I'm not going to participate much more in this, since there isn't really any Django content here (you mention the word Django a few times, but nothing is specific to Django or even uses Django in the solution you've proposed). I think re-evaluating your initial design would be beneficial, though. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
