Про авторизацию на разных доменах второго уровня. Тут используется единый сервер авторизации. У яндекса это passport.yandex.ru. При авторизации на каком-либо проекте пользователь кидается на этот passport, который вас либо авторизует, либо нет. Если авторизует, то возвращает обратно с меткой, подписанной с помощью секретного ключа, и сквозным идентификатором пользователя. Получив и проверив метку, сервер отправляет запрос на passport (ну или какой другой) для получения данных этого пользователя по идентификатору. Обычно данные пользователя сохраняются в локальную пользовательскую базу, чтобы каждый раз не пинать passport (проблему актуализации данных оставлю как домашнюю работу вам). При заходе на новый сервер неавторизованными, вас редиректит на passport. Если вы уже где-то авторизовались, то на passport'е стартанула ваша сессия и вас тут же возвращает обратно уже с идентификатором и подписью. Если же не стартовала, то соответственно возвращает с отметкой, что не авторизован и на локальном сервере вам показывается форма авторизации, ведущая на passport.

То же самое можно и на доменах третьего уровня реализовать, если они будут на физически разных машинах (тут бессмысленно стартовать сессию на весь домен второго уровня).

Для объявлений вам потребуются локальные базы. раз нагрузка будет такой-растакой огромной. Соответственно и админку надо будет делать локальную для модерации объявлений и глобальную для общих данных - это здравый смысл, т.к. модераторы не смогут качественно модерировать объявления из неизвестного региона.

Данные от глобальной админки кидайте по ftp на хосты локальных серверов - самый простой с точки зрения реализации способ.

Вроде по озвученным вопросам описал всё, что необходимо для реализации.

olgatcpip
Есть в Днепропетровске Украинский хостер... единственная беда, серверы располагаются в другой стране вообще.
С другой стороны мой провайдер даёт идеальный пинг до половины хостеров Германии, зато есть парочку провайдеров до которых связь хуже, чем если бы я коннектился в Америку. (Это проверять фактическое расположение серверов надо!!!), ну а по сути - да, если городской - то скорость будет выше.
Единая авторизация: API (как вконтакте), сессия хранится в БД, а не на сервере. Как сказал Никитиан, запрос кидается на какой-то центр, где хранится БД юзеров, потом возвращается на регион.
Единую БД пользователей можно создать через отдельную БД, где будут храниться данные о пользователях, остальные данные работать будешь с внутренними БД для каждого региона.

olgatcpip, опишите заказчику про разбиение базы, сколько проблем это принесёт и что в следствии их, стоить это всё будет раз в пять дороже. Скорее всего эротические фантазии вроде "на городском хостере сайт работает быстрее" от этого уйдут.

olgatcpip
интересное задание, отпиши потом как структуру создавали.

Nikitian, спасибо, очень подробно описал. Остальные вопросы, думаю будут в процессе.....

Я так представляю, passport как бы вместо сессии. Осталось выяснить про секретный ключ и как сделать защищенное его использование. Прокомментируй как формировать ключ и хранить локально стоит ли в БД или в Сессии локальной или в куках?

Сложность основная - это создать взаимодействие. Примеров кода наверно и нет
А главное актуализация скриптов, сменил в одном регионе, сразу продублировать на все... И все таки ветки будут все равно различаться.. Но это пустяки, если пойдет хорошо, начнем нанимать команду.

Сессия стартует как на passport, так и на локальном сервисе. На локальном, чтобы на каждую страницу не дёргать passport, на passport, чтобы он знал кто авторизован и не запрашивать всё время авторизационные данные.

Секретный ключ и подпись им.
На двух серверах имеется одна и та же строка. Задача: использовать эту строку, как секретный ключ для подписи.

//Server1: Signing
$secretkey = '!rf24%Y#$Yh45j45#QW#TY#$5yw54g';
$somedata = 'user_id=1';
$sign = sha1(sha1($somedata).sha1(secretkey));//Алгоритм может быть любой. Крайне желательно необратимый, т.е. хэширование


//Server2: Check signed data
$secretkey = '!rf24%Y#$Yh45j45#QW#TY#$5yw54g';
$data = 'user_id=1';
$sign = 'afafafafafafafafafafafafafafaafafafafafafafa';
if(sha1(sha1($data).sha1($secretkey))==$sign){
// Подпись сходится - данные в $data не были подменены
}

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

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

А вообще vasa_c здравую мысль написал. Первым делом нужно опираться на реальные данные о посещаемости. Я вот сильно сомневаюсь, что это все будет оправдано.

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

И снова к этому вопросу.

Значит нужно сделать секретный ключ. Не проблема.

НО я, анпример, авторизовалась, на a.site.ru В паспорт записала, локально на a.site.ru без проблем определяю, что я авторизована.

Потом иду на b.site.ru И как здесь мне понять, что я авторизован?
Ну, если так b.site.ru?SECRETKEY , то ясно как понять, но тогда и ключ все равно не секретный.

Хочется, чтобы авторизованный на поддомене A, был авторизован автоматом на B
Даже если на B, человек зайдет путем копирования урла в строку браузера.

Вот в этом у меня основная головоломка.

Ясно. Тогда так. Есть phpbb. Установлен. А до него был сайт. С авторзацией. С регистрацией. Вспомнить парольк и все такое.
Как сделать, чтобы авторизовавшись на сайте, мы были автоматом авторизованы на форуме?
Задача тика в тику. Кстати, сервер один в этом случае. Я уже молчу о смене пароля и единой регистрации (это можно в лоб редиректом.).

Но все же. Это решается session_save_path ? Объясните дураку. Решают же такие задачи. авось не сложно.

Мой последний вопрос вообще не о том был.

Я вот как решила делать за неимением лучшего.

При авторизации на site.ru, помимо проверок, получаю с паспорта уникальный ид сессии (его я ещё в базу запиши на паспорте) и записываю этот ид в куку на домен.

setcookie('passport_key', $id_session, time()+60*60, '/', 'webolga.ru');

Таким образом когда мы перейдем на форум, эта кука будет "подрисовываться" и по ней я буду искать в БД запись. Если есть, авторизую локально, если нет, значит гость.

Здесь где-то писали. что куки - не лучший вариант. Мол отключены могут быть. Но лучше вариант мне не приходит на ум.

Если есть механизм лучше, расскажите.

никто куки не отключает обычно
а что мешает в сессии сохранить
или это разные сайты?

передайте значение в урле которым на форум переходите

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

olgatcpip
как вариант, допустим есть домены site.ru, main.site.ru и forum.site.ru
можно сделать так, после авторизации устанавливаем общие куки к домену второго уровня

$secret = 'bolshayaabracadabra';
$user_hash = md5($login. md5($password).$_SERVER['HTTP_USER_AGENT'].$_SERVER['REMOTE_ADDR'].
                     (isset($_SERVER['HTTP_X_REAL IP']) ? $_SERVER['HTTP_X_REAL IP'] : '').
                     (isset($_SERVER['HTTP_X_FORWARDED_FOR']) ? $_SERVER['HTTP_X_FORWARDED_FOR'] : '').
                     (isset($_SERVER['HTTP_ACCEPT']) ? $_SERVER['HTTP_ACCEPT'] : '').
                     md5($secret));

setcookie('user_id', $user_id, $expire, '.site.ru');
setcookie('user_hash', $user_hash, $expire, '.site.ru');

дорабатываем механизм авторизации, если пользователь не был авторизован на текущем субдомене, то проверяем наличие кук user_id и user_hash, и при их наличии на основе $_COOKIE['user_id'] и данных о пользователи из бд, аналогичным образом генерим $user_hash и сравниваем с $_COOKIE['user_hash']
Немного сумбурно изложил, но думаю идея ясна.

так то оно понятно. $user_hash по сложнее в разы чем у меня.
Но не избыточно ли user_id?

Можно в принципе обойтись и одной кукой

setcookie('user_hash', $user_id.':'.$user_hash, $expire, '.site.ru');

но особого смысла не вижу

я планирую как только авторизовался, в БД паспорта записать этот чудо-код.
Затем запомнить этот код или просто флаг поставить в локальной БД у соответствующего ида. Чтоб к паспорту не бегать каждое соединение.

Если перейти на форум, например, локально проверю, что не авторизован (сравню сессию с локальной БД), после этого пойду к паспорту сверяться (здесь сойдется и я запишу этот флаг локально уже на форум). Сравнения по этому коду.... Или же пришлось бы по 2м параметрам ид юзера и код. Одному иду юзера же доверять нельзя.

А при выходе, с паспорта прям в БД и в локальных снять этот параметр. в null установить.

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

К паспорту обращаюсь сугубо с сервера. Курлом. С кучей параметров для доверительного подключения. И напрямую с браузера туда не попасть. Чтобы скрыть место положение паспорта. Но кажется с паспорта таким образом не возможно управлять куками браузера пользователя.

Сильно сложно?

я против этого ничего не имею, именно его я и назвала чудо-код

Я имел ввиду сделать примерно так

а на паспорт возложить только регистрацию новых юзеров, и синхронизацию таблиц users между серверами

killer8080
Привязка к Ip и все такое - это хорошо. Но что мешает 2 параметра угадывать?
Недавно конкурс был. Я четко уяснила, что порой угадывать алгоритм не будут. В лоб. перебором! Наша задача чтобы перебирать запарились, а и вообще забанить частые обращения. Я так поняла нужно подсчитать количество переборов. А для этого увеличить длину того же хэша.
хэши переменной длины - это крутенько, лично мне нравится.
А вот запомнить по хэшу в зависимости от серверной переменной, чтобы забанить это надежней от сниферов по-моему. Нет?

Я на паспорт думаю возложить запись секретика и стерание секретика (вход).
+ контрольные моменты. При этом сайт как работал, так и должен работать. Некоторые параметры вовсе в сесии, те что сейчас используются. Короче как банить и сра.. снифить начнут, так и буду думать. Но идея мне понравилась, я даже чуток усложнила у себя тут.

А т.е. перехватить IP сложно?
Достаточно попросить кликунть к себе. Вообще все параметры увидешь.
Кликни сюда Думаешь IP и все заголовки подставить нельзя.

Логин вообще виден, вон он у тебя killer8080 как правило и на сайте виден. Почта порой тоже не секрет. Ид юзера на форуме у тебя скорее 26630.
Да и логин узнавать не нужно согласно твоему алгоритму
Итого $_COOKIE['user_hash'] я перехватила, в том же месте взяла все-все заголовки сервера ид юзера, а что там, наверняка тем же способом получила, что и хэш.

// если есть куки от других серверов
	elseif(isset($_COOKIE['user_id'], $_COOKIE['user_hash'])){
		$q = mysql_query("
			SELECT `login`, `password`
			FROM `users`
			WHERE `id`=".(int)$_COOKIE['user_id']."  
		"); // Т.Е. МЫ ВЗЯЛИ САМИ ЛОГИН НА СТОРОНЕ СЕРВЕРА
		if(mysql_num_rows($q) > 0){
			list($login, $password) = mysql_fetch_row($q); // ЭТО САМО СОБОЙ ПРОКАТИТ, МЫ ЖЕ ТОЛЬКО ЧТО ИЗ БАЗЫ ИХ ВЗЯЛИ
			if(get_user_hash($login, $password) == $_COOKIE['user_hash']){
				//СЮДА ПОПАЛИ АВТОМАТОМ, ПОТОМУ КАК УКРАЛИ И ХЭШ И ПАРАМЕТРЫ
                                $_SESSION['user_id'] = (int)$_COOKIE['user_id'];
				$_SESSION['auth'] = 1;
			}
		}
	}

Я не хакер, вообще никогда не занимлась этим. НО мне кто-то из здешних форумчан, говорит, кликни по ссылке. Я кликнула. Он все параметры вытянул.
Как серверные перемменные то я догадалась :) а как куки даже не интересовалась. Вот и получается.

Я тут почитала, так просто IP не подменить. Но если хакерить своего соседа или через одного провайдера то получится! )

так. что же получается.
ip не подделать.
зачем тогда такой сложный хэш?
Не достаточно ли сделать хэш зависимым от ip и секрет ключа. Даже если подделают куку, все равно не проникнут, так как ip не подделать

Я не логично рассуждаю?

Кстати, что касается лучшего пинга, при расположении серверов в том же гео регионе что и юзер, утверждение весьма спорно! Время пинга зависит не только от расстояния между хостами, но и от топологии сети - числа хопов и толщины каналов. Например, у меня спидтест на Киев стабильно 92-96 мбит, а на местный, Симферопольский сервер выше 25мб редко поднимается, а всё потому, что мой провайдер не входит в местную точку обмена трафиком Crimea-IX и IP пакеты идут через Киев.
Попробуйте растолковать это заказчику.

А как на счет того, что выборка из 1 000 000 000 записей быстрее будет чем из 100 000 ? это только по одному запросу.

Это решается memcachedом? да?

olgatcpip
Для хайлоадов что выносят, так это медиа контент (картинки всякие), используя CDN. А передать 10кб текста за 5тыщ километров - это не вопрос)

olgatcpip
ага, но это только для контента.