login with subdomains

[tom]

Hello,

I have a application, where I want that users log in to a special
subdomain. For example: The login screen is served at www.agileamp.com
and the user is member of the account with subdomain
test.agileamp.com.

When the user logs in at www.agileamp.com/login/ I want to make sure,
that he gets the session cookie set for his accounts subdomain.
test.agileamp.com.

Any ideas?

regards, Tom

[Lucian Nicolescu]

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-cookie-domain).

Lucian

> --
> You received this message because you are subscribed to the Google Groups "Django users" group.
> To post to this group, send email to django...@googlegroups.com.
> To unsubscribe from this group, send email to django-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
>
>

[tom]

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 <lucia...@gmail.com> 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 <thomas.st...@gmail.com> 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/I want to make sure,

[Lucian Nicolescu]

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

[Cal Leeming [Simplicity Media Ltd]]

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

[tom]

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]"

<cal.leem...@simplicitymedialtd.co.uk> 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 <lucia...@gmail.com>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 <thomas.st...@gmail.com> 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 <lucia...@gmail.com> 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 <thomas.st...@gmail.com> 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,

[tom]

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

> > > 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 <thomas.st...@gmail.com> 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 <lucia...@gmail.com> 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 <thomas.st...@gmail.com> 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,

[Cal Leeming [Simplicity Media Ltd]]

Glad you managed to get it working! :)