Сен 13

История построения одного веб-портала.

PHP, SQL, PROграммирование Комментировать

Дмитрий Супруненко (abolabo_at_gmail.com)

Постовой:
Реалити-шоу о домашнем интернет-бизнесе
партнерские программы по кликам
Качественный контент для сайтов
Интернет магазин офисной мебели centeroffice.ru.

Предисловие.

В последнее время трудно найти крупную компанию, которая не мечтала бы иметь свой корпоративный веб-портал. Сначала какой-нибудь отдел сделает свой сайт, потом другой отдел сделает свой, и потом еще один и на каждом сайте свой пароль и попробуй это все запомнить, не то чтобы разобраться что да как. И вот тогда возникает потребность объединить все сайты в один портал. Но как сделать, если они разнесены физически, и даже не находятся в одной сети и связаны посредством интернет? Далее речь пойдет как раз о таком случае, веб-портал с горизонтальным масштабированием (через добавление серверов).

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

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

Также мне было показан приказ о создании на предприятии веб-портала, который подразумевал единую базу пользователей для всех веб-ресурсов предприятия. Стоит сразу читателю прояснить ситуацию с подчинением. Я работаю в отделе, который разрабатывает программы для технологической части бизнес-процесса предприятия, и этот отдел территориально удален от офиса (хвала Господу! ), в котором есть свой отдел ИТ. Вот как раз он разработал и внедрил официальный и внутрикорпоративный сайты предприятия. Мои же сайты находятся на физически разнесенных веб-серверах службы, в состав которой входит отдел, где я работаю.

Что мы имеем.

Итак, мы имеем один центральный сайт и множество региональных, каждый со своей административной консолью. Каждый сайт предприятия имеет как минимум два окошка для доступа, белый ip-адрес, для доступа из интернет, и внутренний для доступа из корпоративной сети, центральный DNS-сервер для интернета, реплики его для региональных сетей.

Что требуется и технические условия для этого.

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

Ограничения:

Регистрация и изменение профиля пользователя должна происходить только на центральном сайте.
Доступ ко всем сайтам портала должен быть децентрализованным. При падении центрального сайта, с которого производится аутентификация, должен быть альтернативный вход с использованием базы пользователей регионального сайта для повышения доступности сервиса.
Должны использоваться только 80 и 443 порты. Данное условие навязано суровой реальностью (если сервер стоит где-нибудь в конторе, у которой арендуется помещение со их сисадминами, то там, как правило, открываются только 80й и 443й порты для работы в интернет арендаторам и добиться открытия какого-нибудь еще порта, например для репликации базы данных, не представляется возможным).
Раздача прав доступа не должна производится одним кликом. Так как сайты все разные, с разным функционалом и своими особенностями, то и настройка доступа должна быть более тонкая для каждого, отдельно взятого пользователя.

Как делалось и что получилось.

Начнем с базы пользователей. На совещании двух отделов по ИТ было принято решение хранить общую базу пользователей на центральном сервере, а на региональных только тех, кто имеет доступ к ресурсу. Стоит напомнить, что права доступа на центральном сайте даются исключительно на ресурс, а права доступа к тем или иным страницам выставляются на каждом сайте отдельно для каждой группы пользователей. Это было сделано по причине разнообразия предоставляемых информационных услуг и невозможности выставить права пользователю одним кликом. Ну, например, мне на сайте нужно пользователя привязать к полю своей таблицы, чтобы он получал ограниченную информацию. Делать привязку идентификатора пользователя к свой таблице через написание отдельной админки не представляется возможным, так как мне надо будет либо перетягивать таблицу на сервер, где стоит админка портала, либо разрешать доступ непосредственно к своей базе, что запрещено техническими условиями(см. выше про открытые порты).

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

выборка списка пользователей, что сейчас имеют доступ к сайту.
проверка на добавленных вручную юзеров(на случай срочного предоставления прав доступа. Админ регионального сайта может добавить юзера со специально сформированным идентификатором). Если такие пользователи есть, они импортируются в центральную базу с присвоением нового идентификатора, ну и, соответственно, заменяется ид на удаленном ресурсе на новый, уже, так сказать, окончательный.
добавление в базу тех пользователей, которым недавно были даны права на сайт.
удаление тех, у которых право доступа отняли. После удаления из списка пользователей сайта эти пользователи теряют все права доступа к страницам. Если с центрального сайта кого-то из них опять добавят, он будет иметь гостевой уровень доступа. Для блокировки доступа ко всем веб-сайтам используем поле expired в таблице пользователей. В таблице перевязки пользователя с группой пользователей регионального сайта также есть поле expired, которое случит для блокировки доступа пользователя на конкретном региональном веб-сайте, а не во всем веб-портале.
обновление данных пользователя (например, пароль), основываясь на поле последнего изменения строки в таблице пользователей.

Чего мы добились подобной схемой? Ответ прост — повышения доступности сайтов. Если бы мы сделали вход на сайт только через центральный сервер, то сильно бы зависели от провайдеров, к которым подключен центральный сайт. В случае, когда центральный сайт не отвечает, мы просто набираем нужный нам адрес в адресной строке броузера и входим на сайт, так сказать, локально, опираясь на список пользователей регионального сервера. Если же мы пытаемся зайти на сайт при работающем центральном сервере, то региональный сервер проверит его доступность и перенаправит пользователя для последующего входа.

Так как все сайты находятся в домене, например yourdomain.com, то в php.ini каждого из веб-серверов прописываем параметр session_cookie_domain = . yourdomain.com. Теперь все куки, выставленные на любом из сайтов будут видны другим сайтам этого домена. Сделано это для того, чтобы идентификатор сессии не менялся при переходе от сайта к сайту.

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

На центральном сервере создаем сайт, который будет принимать статистику от региональных чтобы знать какая сессия активна и какому пользователю она принадлежит. Назовем его statistic.yourdomain.com. Этот сайт нам будет также возвращать идентификатор пользователя по идентификатору сессии, когда происходит переход юзера от одного регионального сервера к другому. Естественно, не просто так, а по шифрованному каналу с уникальным ключом шифрации для каждого веб-сервера.

Далее нужно внимательно изучить схему перенаправления. Не смотря на свою сложность она позволяет пользователю записать в куки только идентификатор сессии и все. Все остальные действия производят сервера.

Послесловие

Данная статья не является всего лишь теорией, а описывает реально работающую схему. В нашем случае она работает на FreeBSD+apache+php+postgresql+mysql(на центральном сайте), но вполне пригодна и для других программых реализаций.

Просьба все отзывы и замечания присылать на abolabo_at_gmail.com.