Hey Lucian, that sounds solid. I will implement that together with an additional auth backend. Looking into the option of subclassing remoteuserbackend and adding the functionality there but also leverage the remote_user META variable. That sounds to me like a very robust solution. Thanks for describing in that detail!
I keep you posted about the final implementation. regards, tom On 25 Mai, 13:39, "Cal Leeming [Simplicity Media Ltd]" <[email protected]> wrote: > Hi OP, > > To do this, you need to use what's known as a 'handoff'. This basically > means handing off an authenticated session to a different FQDN. > > There are several ways you can do this, but I would recommend using the > following: > > - Create a receiver URL on each FQDN which can be handed off to (in this > case whatever.* and www.*), called /handoff/(.*) > - Create a secret string inside the settings file, which will be used to > build a hash of the username and password. > - From the originating site, generate a hash of the username and password > (salted with the secret string), store this hash (along with the original > username and password) in a cache server for 60 seconds, and redirect the > user to the new domain on /handoff/insert_hash_here. > - On the receiving site, extract the hash, and check the cache server to > make sure it exists, and then re-authenticate the user manually using > login() with the username and password extracted from the cache entry. > > This is pretty much the industry standard way of doing things properly. > There are easier (and less secure) alternatives, but I would highly > recommend using this (it's certainly what we use anyway). > > Cal > > On Wed, May 25, 2011 at 12:00 PM, Lucian Nicolescu <[email protected]>wrote: > > > > > You're right, it would be valid for all subdomains. Hmm ... I can't > > see a solution without a hack. Eg: authenticate the user on > > agileamp.com and at the same time do a AJAX request to the subdomain's > > authentication clone. > > > This way the a cookie would be set only for the TLD (agileamp.com) and > > for the subdomain (whatever.agileamp.com). The two sessions would be > > different but I guess that's okay, right? > > > Now that I think of it it would be simpler to make the session global > > and add the subdomain restriction to it. This way when the user visits > > a subdomain the first thing you do is to check the restriction in the > > session. > > > Let us know what you come up with! > > > Lucian > > > On Wed, May 25, 2011 at 12:46 PM, tom <[email protected]> wrote: > > > well, I thought about this, but wouldn't then the session be valid for > > > test.agileamp.com as well as for test2.agileamp.com? I want to set the > > > session only for test.agileamp.com (the subdomain where the account > > > belongs to). > > > > On 25 Mai, 10:30, Lucian Nicolescu <[email protected]> wrote: > > >> I think you can use the SESSION_COOKIE_DOMAIN and set it up to > > >> ".agileamp.com" (docs: > >http://docs.djangoproject.com/en/dev/topics/http/sessions/#session-co...). > > > >> Lucian > > > >> On Tue, May 24, 2011 at 11:46 PM, tom <[email protected]> wrote: > > >> > Hello, > > > >> > I have a application, where I want that users log in to a special > > >> > subdomain. For example: The login screen is served atwww.agileamp.com > > >> > and the user is member of the account with subdomain > > >> > test.agileamp.com. > > > >> > When the user logs in atwww.agileamp.com/login/Iwant to make sure, > > >> > that he gets the session cookie set for his accounts subdomain. > > >> > test.agileamp.com. > > > >> > Any ideas? > > > >> > regards, Tom > > > >> > -- > > >> > You received this message because you are subscribed to the Google > > Groups "Django users" group. > > >> > To post to this group, send email to [email protected]. > > >> > To unsubscribe from this group, send email to > > [email protected]. > > >> > For more options, visit this group athttp:// > > groups.google.com/group/django-users?hl=en. > > > > -- > > > You received this message because you are subscribed to the Google Groups > > "Django users" group. > > > To post to this group, send email to [email protected]. > > > 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. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Django users" group. > > To post to this group, send email to [email protected]. > > 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. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected]. 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.
