Единый вход в Django и сайт Php: кросс-доменный вход? - PullRequest
2 голосов
/ 20 июля 2009

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

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

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

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

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

Как бы вы справились с этим?

Ответы [ 4 ]

7 голосов
/ 20 июля 2009

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

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

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

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

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

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

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

6 голосов
/ 07 марта 2010

Хорошо, это как аутентифицировать пользователя 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 сохраняет пароли, а именно:

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

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

sha1$63a11$85a93f217a72212b23fb0d5b95f3856db9575c1a

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

Так, кто вы производите зашифрованный хеш в PHP? Вы просто объединяете соль и необработанный пароль и хешируете его с помощью алгоритма, в данном случае sha1:

<?php 

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

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

?>

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

1 голос
/ 20 июля 2009

Вы можете использовать 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, возможно, потребуется сохранить кэш воспроизведения, чтобы другие материалы могли использоваться только один раз.

0 голосов
/ 20 июля 2009

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

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

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

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

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

3) Идентификатор сеанса PHP, переданный через GET:

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...