Кросс-доменная авторизация AltoCMS + PhpBB

Когда систем становится больше чем одна но меньше чем множество, приходит пора задуматься о том, как же жить дальше. Правильное и красивое решение — перейти на следующий уровень и запилить авторизацию всех систем через единый паспорт-хост. Но что делать, когда такие крупномасштабные изменения не целесообразны, но в тоже время как-то надо увязать CMS и, к примеру, форум? Если:
— системы расположены в одном домене второго уровня;
— БД в идеале находятся в на одном сервере (как минимум в скриптовой доступности);
— FE в идеале на одном сервере.

В таком случае можно сходить по пути минимализма и реализовать кросс-доменную авторизацию в рамках СУБД. Как правило небольшие подобные системы для хранения данных используют MySQL, а обрабатывают эти данные исключительно в основном в PHP. В тоже время MySQL уже вырос из простого хранилища в более-менее СУБД.

Чтобы реализовать сабж, нам надо результат авторизации (а это, обычно, данные в БД + cookies + php session данные) сделать доступными для обоих всех систем.

С данными БД проще всего — при помощи триггеров и (в особо сложных случаях) хранимых процедур организовываем двухстороннюю репликацию данных. Чтобы не пришлось переписывать одну или несколько систем, а пользователи не потеряли свои пароли и данные, необходимо:
— во всех системах реализовать единый механизм хеширования паролей;
— реализовать плавную репликацию юзерских данных (как минимум таблица пользователей) из исходной в остальные системы;
— реализовать репликацию сессионных данных, хранящихся в БД между всеми системами.

С cookies чуть сложнее. Древние системы, бывает, работают не в стандартной PHP сессии, а хранят всё подряд в куках. Здесь надо выбирать, или в код каждой системы вносить генерацию кукисов для всех остальных, или запилить авторизацию таким образом, чтобы каждая система восстанавливала свои куки сама из БД по ключу из PHP сессии. Я пошел по второму варианту.
Формироваться cookies должны для корневого домена второго уровня дабы быть доступными для всех систем (как минимум идентификатор PHP сессии).

PHP сессии. В наиболее удобной системе добавляем в процесс авторизации извлечение из БД в PHP сессию первичных ключей для всех систем (как правило это user_id'ы). Затем останется только минимально вмешаться в код и научить каждую систему брать из PHP сессии необходимые первичные ключи и восстанавливать все остальные данные (куки).

Репликацию каждый с каждым можно настроить как через сводную таблицу, так и напрямую. Во втором случае (по которому пошёл я) надо для передачи репликационных ключей либо добавлять поле, либо аккуратно использовать имеющиеся не используемые :). Идея проста — если данные пришли из другой системы, то триггер завершается, если же данные пришли из веба — триггер реплицирует данные по остальным системам.

В более сложных случаях географическую удалённость FE и BE можно преодолеть через фичу выполнения скрипта из СУБД.

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