> > This is a good question, and I haven't come to a conclusion. Probably > > it'll be the Django built-in application-based authentication, > > particular to each Django instance. There will be a master map of all > > users to their respective Django instance. > > That seems a bit like a chicken and egg problem. At the point that you > need to make the decision as to which Django instance to use, you > haven't yet logged in them in. Thus if you are going to try and use > their own instance to log them in, that can't work.
If usernames are unique, e.g. email addresses, there can be a map, e.g.: [EMAIL PROTECTED] => DjangoInstanceA, [EMAIL PROTECTED] => DjangoInstanceB, This User-Instance mapping could happen prior to authentication if, when the user submits login-information from a form, a process (demultiplexer) decides based upon the username which Django instance to direct the login-request to. The Django instance then handles all subsequent requests. I don't know if this will actually work. > If you use one special Django instance to handle login, then issue is > having any session information in that instance also used by the other > instances such that when you go to actual instance on subsequent > requests, it knows you are allowed to access it. Perhaps HTTP Basic authentication might be the simplest solution. :) > I'll describe any solution in terms of HTTP Basic authentication first > and then can let you think about authentication when you see how the > multiplexing is achieved. That'd be great! --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
