Hey, I implemented it that way:
One view takes the request and the password, encrypts username and password and creates a sha1 hash with the pickled data. This pickled data is then stored in the cache with the hash as key. Another method receives the hash as a URL parameter and then fetches the data from the cache. Decrypts the user data and logs the user in. This method is a view beneath the customers subdomain. Many thanks for your help! regards, tom On 25 Mai, 14:06, tom <[email protected]> wrote: > 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 thesubdomain's > > > authentication clone. > > > > This way the a cookie would be set only for the TLD (agileamp.com) and > > > for thesubdomain(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 thesubdomainrestriction to it. This way when the user visits > > > asubdomainthe 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 (thesubdomainwhere 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 withsubdomain > > > >> > test.agileamp.com. > > > > >> > When the user logs in atwww.agileamp.com/login/Iwantto make sure, > > > >> > that he gets the session cookie set for his accountssubdomain. > > > >> > 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.
