Glad you managed to get it working! :) On Thu, May 26, 2011 at 10:47 PM, tom <[email protected]> wrote:
> 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. > > -- 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.
