Django единый вход и сайт Php: перекрестный домен Логин?

Question

Я создаю небольшое приложение в качестве службы в django, и теперь самое время интегрировать его на некоторых веб-приложениях PHP для клиентов.

Наш клиент A из домена www.a.com обрабатывает свою собственную аутентификацию для своих пользователей и, возможно, использует файлы cookie для сеансов.

Как я могу войти в систему пользователей из своего домена, также выполнил вход в мое приложение Django dommain www.b.com/clientA/?

Я вижу, как я могу сделать их reloggin на моем домене и использовать authbackend для проверки учетных данных в домене A, но это означает, что пользователю нужно будет ввести свой логин/пароль дважды: на www.a.com и www.b. ком.

Доступ к файлу cookie из домена www.a.com невозможно из соображений безопасности, я думаю.

Как вы справитесь?

Answer 1

Вы считаете, что использование cookie-файлов из другого домена не может быть доступно. Однако, если он находится в субдомене, вы должны иметь доступ к файлам cookie, если они установлены правильно.

Если вы абсолютно должны иметь их на совершенно разных доменах, это будет немного сложно. Если вы не можете изменить существующий PHP-код, вы можете в значительной степени забыть об этом.

Одним из вариантов будет использование OpenID - это может быть самый простой способ справиться с этим, так как существуют библиотеки OpenID, доступные для PHP и Python. OpenID позволит вам иметь один знак, например, аутентификацию, и поскольку он уже используется на разных сайтах, он доказан и работает.

Другой вариант - создание пользовательской системы единого входа.

Основная идея заключается в том, что, когда пользователь приходит на ваш сайт, вы направляете их на сайт входа. Это может быть либо в PHP, либо в Python, или отдельно. Здесь пользователь будет входить в систему, а затем логин генерирует секретный ключ - это может быть хэш, случайная строка, независимо от того, насколько она не предсказуема - и пользователь перенаправляется обратно на основной сайт с помощью ключа.

Главный сайт затем видит, что у пользователя есть ключ, и отправляет запрос на сайт входа за кулисами, чтобы проверить ключ пользователя.

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

Answer 2

Вы можете использовать переадресацию HTTP взад и вперед. Когда пользователь обращается к www.b.com, а cookie не установлен, перенаправляйте его на www.a.com/crosslogin?return_to=URL&challenge=stuff. На a.com проверьте файл cookie, и если он установлен, перенаправите на URL?verified=otherstuff.

Для этого потребуется криптография с криптозащитой, если вы хотите, чтобы пользователи предотвращали подделку аутентификации. a.com и b.com необходимо настроить общий секрет, и материал зашифрован этим секретом. другие вещи также зашифрованы этим секретом; при расшифровке он дает кортеж (материал, пользователь). b.com, возможно, потребуется сохранить кеш воспроизведения, чтобы убедиться, что другие файлы могут использоваться только один раз.

Answer 3

Я вижу следующие варианты:

1) Использование Open ID, как Яни Hartkainen предложенные. Это может быть наилучшим решением.

2) Используйте один домен через HTTP обратного прокси-сервера:

Используйте обратный прокси-сервер HTTP поставить как приложение PHP и приложения Джанго на том же домене. Это даст вам доступ к файлам cookie сеансов вашего приложения php.

После того, как вы получите идентификатор сеанса php в своем приложении django, запустите запрос к приложению PHP с установленным cookie сеанса, чтобы проверить, кто входит в систему. К сожалению, для этого может потребоваться очистка html или реализация простой службы в приложении PHP, будет возвращать имя зарегистрированного пользователя. Как только вы получите зарегистрированного пользователя, вы можете авторизовать его в своем приложении django.

3) PHP идентификатор сессии передается через GET:

Изменить PHP приложение, чтобы добавить идентификатор сессии в качестве параметра ссылки на ваше Джанго приложения. Например просить клиентов обратиться к вашему веб-сайт следующим образом:

<yourwebsite.com>/?client_session_id=<session_id>&client_name=<client_name> 

После того, как вы получите идентификатор сеанса вы можете аутентификации пользователя, как описано в пункте 2.

Answer 4

Хорошо, это как для аутентификации Django пользователя из PHP или как «читать» пароль Django с PHP.

Я думаю, что OpenID является лучшим решением, но я должен был выполнять аутентификацию пользователей Django в PHP приложение обмена ту же базу данных сегодня и это, как я решил:

<?php 

/* Generates crypted hash the same way as Django does */ 
function get_hexdigest($algorithm, $salt, $raw_password) { 
    if (!array_in($algorithm, array('md5', 'sha1'))) { 
     return false; 
    } 
    return $algorithm($salt.$raw_password); 
} 

/* Checks if password matches the same way Django does */ 
function check_password($raw_password, $django_password) { 
    list($algorithm, $salt, $hsh) = explode('$', $django_password); 
    return get_hexdigest($algoritm, $salt, $raw_password) === $hsh; 
} 

?> 

Ключ должен понять формат, в котором Django сохраняет пароли, которые:

[алгоритм] $ [соль] $ [хеш]

Так, например, у меня был «администратор» пользователь с паролем «администратором» и поле пароля в AUTH_USER строке был:

sha1$63a11$85a93f217a72212b23fb0d5b95f3856db9575c1a 

Алгоритм «SHA1», соль, которая была генерируется случайным образом является «63a11» и зашифрованный хэш «85a93f217a72212b23fb0d5b95f3856db9575c1a».

Итак, кто вы производите зашифрованный хеш в PHP? Вы просто сцепить соль и необработанный пароль и хэш его с алгоритмом, в данном случае, sha1:

<?php 

$salt = '63a11'; 
$pass = 'admin'; 

echo sha1($salt.$admin); // prints "85a93f217a72212b23fb0d5b95f3856db9575c1a" 

?> 

Это было не трудно! Я получил его, прочитав соответствующий код в источниках Django.