.htpasswd синхронизировать на разных серверах

Часть сайта работает на одном сервере A, другая, в силу скриптов и свободнго места, может работать только на другом сервере B. На сервере А контент закрыт связкой .htaccess + .htpasswd, мемберов обновляет скрипт и всё содержимое сайта B должно подчиняться этому же правилу.

Как организовать так, чтоб сёрфер не замечал того, что сайт разбит на разные сервера, авторизировался один раз и ходил по сайту, независимо от того, с какого сервера тянется контент?

вариант:
на домене А ставим скрипт, гребущий .htpasswd и пересылающий его на домен Б. его запуск - либо по крону, либо(идеал) как-то прикрутить к админке. ну а на домене Б скрипт-приемник.
что-то вроде:

Код:

$ht = base64_encode(file_get_contents('.htpasswd'); $options = array(    CURLOPT_URL => 'адрес скрипта-приемника',    CURLOPT_RETURNTRANSFER => true,    CURLOPT_POST => true,    CURLOPT_POSTFIELDS => array(       'action' => 'htpasswd',       'pass' =>'thispasswordistoosimple',       'htpasswd' => $ht,    ) ); $ch = curl_init(); curl_setopt_array($ch, $options); $response = curl_exec($ch); curl_close($ch);

приемник:

Код:

if ($_POST['action'] == 'htpasswd' && $_POST['pass'] == 'thispasswordistoosimple') {    $ht = base64_decode(trim($_POST['htpasswd']));    file_put_contents('.htpasswd', $ht);    echo "written";    exit(); };

А с какой скоростью эта синхронизация произойдёт?
Юзеру надо будет переавторизироваться при переходе с одного сервера на другой?
ПС Я хотел домен сервера B реализовать как субдомен, чтоб максимально приблизить оба сервера к одному и тому же сайту.

Vyacheslav писал:

А с какой скоростью эта синхронизация произойдёт?

мгновенно, если будет как вставка в админку

Vyacheslav писал:

Юзеру надо будет переавторизироваться при переходе с одного сервера на другой? ПС Я хотел домен сервера B реализовать как субдомен, чтоб максимально приблизить оба сервера к одному и тому же сайту.

надо будет, браузер на субдомен логин/пароль не передаст, только внутри домена
тут надо какой-то другой вариант авторизации курить, либо на домене Б убирать ее вообще, а защиту контента делать по рефереру или еще как-то.
распиши что на А, а что на Б лежит)

единственный нормальный способ - это чтобы тот скрипт, который меняет пароли, сам всё и синхронизировал

bari писал:

мгновенно, если будет как вставка в админку

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

Я решал подобную проблему написанием кастомной аутентификации через открытый ключ на серверах и приватный - на странице логина, юзеру выдается подписанная кука, с которой его пропускает сервер. Плюс ко всему - проверка и доступ к базе осуществляются только в момент авторизации, дальше кастомный апачевский модуль просто расшифровывает у каждого запроса в мемберку куку (декрипт по public key - процедура дешевая), смотрит, валиден ли еще тикет, подходит ли он для этого сайта (т.е. можно юзера хоть на 10 сайтов залогинить) и, если что-то не так - направляет юзера на страницу логина. Это, пожалуй, лучший способ - какая-то синхронизация .htpasswd сбойнет время от времени там или сям.

Dr.Syshalt писал:

открытый ключ на серверах и приватный - на странице логина, юзеру выдается подписанная кука, с которой его пропускает сервер. Плюс ко всему - проверка и доступ к базе осуществляются только в момент авторизации, дальше кастомный апачевский модуль просто расшифровывает у каждого запроса в мемберку куку (декрипт по public key - процедура дешевая), смотрит, валиден ли еще тикет, подходит ли он для этого сайта (т.е. можно юзера хоть на 10 сайтов залогинить) и, если что-то не так - направляет юзера на страницу логина. Это, пожалуй, лучший способ - какая-то синхронизация .htpasswd сбойнет время от времени там или сям.

+1, добротный, дешевый и надежный способ
Мерфи действительно будет в ноле практически