django: возможно ли войти в поддомен из другого домена? - PullRequest
Новая
       23

django: возможно ли войти в поддомен из другого домена?

2 голосов
/ 27 января 2011

Дело в том. У меня есть одно приложение Django, обслуживающее разные сайты.

site1.myapp.com
site2.myapp.com

Пользователи входят в систему через стороннюю систему единого входа, которая затем перенаправляется (включая POST проверки) на https://myapp.com/auth/

Тем не менее. так как все мои пользователи принадлежат только одному «сайту», мне бы хотелось, чтобы myapp.com/auth/ для входа пользователя на соответствующий сайт, напр. site1.myapp.com или site2.myapp.com, а затем перенаправить их на этот сайт…

Это вообще возможно ?? или я должен идти об этом совершенно по-другому? :)

Я должен упомянуть, что когда дело доходит до общего использования приложения, у меня есть промежуточное ПО для поддоменов, чтобы пользователи всегда посещали только субдомен (и данные), для которых действительна их учетная запись.

Причина, по которой я хочу использовать субдомены, заключается в том, чтобы пользователям было проще запомнить URL своей учетной записи, сохраняя при этом преимущества, связанные с необходимостью поддерживать только одно приложение django.

спасибо. надеюсь, что вы можете помочь :)

С уважением.

1021 * Пита *

Ответы [ 2 ]

7 голосов
/ 19 сентября 2015

Я знаю, что этот вопрос старый, но так как Google привел меня сюда, я добавлю эти ссылки

Этот ответ касается (A) аутентификации на поддоменах и (B) определения того, какиесубдомен используется для возможного перенаправления пользователя

A.1.Если вы хотите разрешить все (подстановочные) субдомены * .myapp.com , это достигается добавлением одной строки в settings.py:

SESSION_COOKIE_DOMAIN=".myapp.com"

Подробно здесь (SO, 2009) , здесь (SO, 2010) и в Django docs

Примечание: вход в систему теперь не будет работатьlocalhost, поэтому у вас есть два варианта, если вам нужно войти и выйти на localhost:
1: закомментировать эту строку в файле settings.py или
2: изменить файл / etc / hosts так, чтобы он включал следующее:

127.0.0.1 localhost
127.0.0.1 dev.myapp.com

Теперь вы можете посетить dev.myapp.com в своем браузере, и он будет фактически взаимодействовать с 127.0.0.1, а не с вашим живым веб-сайтом.(Теперь через dev.myapp.com, site1.myapp.com, site2.myapp.com и myapp.com, если вы входите / выходите из одного, вы будете входить / выходить из них всех.)

А.2.Если вы хотите разрешить перекрестную аутентификацию только между этими двумя поддоменами , т. Е. Они не будут зарегистрированы в site3.myapp.com, тогда это будет немного сложнее

B.Чтобы просмотреть используемый поддомен В django есть более интересные пакеты для управления поддоменами, но вы можете просто грубо взглянуть на request.META ['HTTP_HOST']: 

try:
    http_host = request.META['HTTP_HOST']
    # alternative: http_host = request.get_host()
except KeyError:
    http_host = None
    print "Can't find HTTP_HOST"

if http_host and '.myapp.com' in http_host:
    subdomain = http_host.split('.myapp.com')[0]
else:
    subdomain = ''

Затем проверьте,доволен request.user использованием этого subdomain.Используйте что-то вроде HttpResponseRedirect, чтобы отправить их на другой поддомен, если хотите.Если вы выполнили A.1 или A.2 выше, по мнению вашего приложения, они были тем же пользователем (уже вошли в систему) в новом subdomain.myapp.com после перенаправления (им не нужно входить в систему).снова).

Пример: если пользователь создает учетную запись на сайте i Ireland.myapp.com и вы хотите, чтобы он всегда оставался на этом сайте, то при попытке зайти на сайт usa.myapp.com он все равно будет авторизован., вы можете идентифицировать их и отправить обратно на ireland.myapp.com (вымышленный пример, а не метафора для иммиграции!)

0 голосов
/ 27 января 2011

В Django у вас есть понятие сайтов . Вы можете создать свой собственный логин в представлении . Если этого недостаточно, вы можете создать свой собственный аутентификационный бэкэнд .

...