forum.lissyara.su

Всем привет!

Стала задача усовершенствования модуля авторизации (под PHP_5.2.11 и MySQL_5.1.35).
Существующий использует только сессии PHP, все данные о пользователях хранит в MySQL, пароли - в зашифрованном виде.
Существующая система авторизации подвязана к почтовику и его веб-клиенту.

Компания-заказчик является владельцем цепочки доменов по всему миру, но на данный момент использует только домен в зоне .COM. Теперь появилась необходимость разделить пользователей на географические сегменты по странам: Россию - в RU, Украину - в UA... Однако сертификат SSL компания покупает один и он будет установлен только на одном сайте, скажем, ssl.securedomain.com.

Поставленные задачи: (на сегодня)

1. 1. Безопасность;

• 2. Сквозная авторизация по всем сайтам используемых эту-же систему.

• 3. Возможность сохранять пароль пользователями. (учитывая п.1).

Если кто работал над чем-нибудь подобным, поделитесь знаниями.

Спасибо.

kozak писал(а):

• 2. Сквозная авторизация по всем сайтам используемых эту-же систему.

гугли на "кросс-доменная авторизация"

kozak писал(а):

• 3. Возможность сохранять пароль пользователями. (учитывая п.1).

где сохранять их? где их не сохраняют?

kozak писал(а):

1. 1. Безопасность;

может по гуглить нужно?

тут долго рассказывать... варианты разные можно...

• привязать сессию к ip чтобы не украли
• хранить сессии в MySQL
• смотреть чтобы боты не регистрировались
• посмотреть как на webmoney
• пароль криптографированный, не просто хэшированный md5crypt говорят достаточно

а какие ты пробовал варианты увеличения безопасности?

ProFTP писал(а):а какие ты пробовал варианты увеличения безопасности?

пока ничего существенного...

ProFTP писал(а):

• привязать сессию к ip чтобы не украли
• хранить сессии в MySQL
• смотреть чтобы боты не регистрировались
• посмотреть как на webmoney
• пароль криптографированный, не просто хэшированный md5crypt говорят достаточно

Из перечисленного списка не имею понятия как:

• привязать сессию к ip чтобы не украли
• хранить сессии в MySQL

По некоторым статьям из сети удалось настругать на колене такую схему:

1. Входим на домен http://example.de кликаем на Login
2. Нас редиректит на https://ssl.example.com, где мы вводим логин/пароль
3. При успешной авторизации нас перебрасывает на тот-же https://ssl.example.com/secure_auth_page где находятся изображения, загружаемые с каждого домена:

• http://example.com/php_image?ssid=CRYPT_USER_ID
  http://example.ru/php_image?ssid=CRYPT_USER_ID
  http://example.ua/php_image?ssid=CRYPT_USER_ID
  http://example.de/php_image?ssid=CRYPT_USER_ID

.
4. На каждом из доменов проверяем корректность CRYPT_USER_ID и создаем сессию, после чего перебрасываем на исходный сайт http://example.de

Система работает, но тут появляются такие проблемы:

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

P.S. Cookies не использую вообще. Не вижу необходимости.

kozak писал(а):При успешной авторизации нас перебрасывает на тот-же https://ssl.example.com/secure_auth_page

в этот момент и надо стартовать новую авторизованную сессию, а не давать пользователю ссылки

zg писал(а):в этот момент и надо стартовать новую авторизованную сессию, а не давать пользователю ссылки

Ок. Спасибо. Я уже к этому пришел. )

Есть ли способ использовать одну сессию несколькими доменами?
Обязательно использовать iframы или файлы типа http://example.ua/php_image?ssid=CRYPT_USER_ID для установления сессий на других доменах?

kozak писал(а):Есть ли способ использовать одну сессию несколькими доменами?

только, если передвать идентификатор сессии через ссылки, по другому никак. Сессия привязывается к куке, а кука к домену, поэтому и остаётся только ссылка.

Можно ли установить сессию или куку на домене "exaple2.eu" с домена "exaple1.eu" используя XMLHttpRequest?

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

kozak писал(а): Из перечисленного списка не имею понятия как:

• привязать сессию к ip чтобы не украли

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

Зачем тогда вообще в данном случае использовать куку?
Выходите или закрываете браузер, сессия закрывается, входите - создается. Почему бы не исользовать только сессии?

kozak писал(а):Зачем тогда вообще в данном случае использовать куку?

куку использует сессия, чтобы не передавать каждый раз идентификатор сесии в адресной строке.

kozak писал(а):Зачем тогда вообще в данном случае использовать куку?
Выходите или закрываете браузер, сессия закрывается, входите - создается. Почему бы не исользовать только сессии?

я же не знаю что там у вас, лучше куки используйте, если вам все равно, то поставьте шифрование - и все! и может некоторое, то что написано выше...

zg писал(а):куку использует сессия, чтобы не передавать каждый раз идентификатор сесии в адресной строке.

Спасибо. Все стало на свои места.

ProFTP писал(а):я же не знаю что там у вас, лучше куки используйте, если вам все равно, то поставьте шифрование - и все! и может некоторое, то что написано выше...

Алгоритм ясен. Спасибо.

Алгоритм, стал такой: авторизируемся, если OK - то IFRAMEом устанавливаем сессии и куки на всех GEO-доменах затем по кукам проверяем авторизированы мы или нет, и если нет то выбрасываем на страницу авторизации.

Если что не так, поправьте.

kozak писал(а):то IFRAMEом устанавливаем сессии и куки на всех GEO-доменах

а зачем для всех сразу?