Совместное использование / прокси сеансов CodeIgniter между несколькими экземплярами CI в одном домене - PullRequest
0 голосов
/ 14 июня 2011

У меня есть следующие настройки:

Site1 (Core) at Core.example.com
Site2 (Work1) at Work1.example.com
Site3 (Work2) at Work2.example.com

и т. Д. ... Я просто использую Work1 в обсуждении, но проблема относится ко всем Work сайтам

Идея заключается в том, что Core используется для входа в систему, платежей, управления учетными записями и т. Д., А рабочие места предлагают функциональность, которая достаточно различна для оправдания отдельных экземпляров CI / Dbs / и т. Д.

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

Проблема, с которой я столкнулся, заключается в том, что я хочу разрешить, например, Work1 совершать звонки на Core от имени пользователя/ как пользователь - для таких вещей, как обновление данных учетной записи пользователя, получение списка доступных пользователю услуг и т. д.

В настоящее время я пытаюсь сделать это через CURL.Если я прочитал файл cookie сеанса Core в HTTP-запросе, сделанном клиентом, к Work1 и вставил его в запрос CURL с Work1 до Core, Core не примет его в качестве действительного файла cookie сеанса,Я не уверен, связано ли это с разными IP-адресами (Client vs Work1) или чем-то еще.

К сожалению, мне нужно Work1, чтобы иметь собственную базу данных, поэтому совместное использование БД не является жизнеспособнымвариант.Тем не менее, я использовал один и тот же ключ шифрования на всех сайтах, чтобы можно было расшифровывать / анализировать файлы cookie (или что-либо еще), как это требуется на любом сайте.

Может кто-нибудь подсказать, как я могу убедить Core, чтозапрос от Worker1 с пользовательским Core сессионным cookie на самом деле от пользователя?

1 Ответ

0 голосов
/ 21 июля 2011

В конце концов я смог обойти это, прочитав cookie и вставив его в запросы curl. Мне также пришлось обрабатывать обновления файлов cookie сеанса, полученные с помощью CURL, переупаковывать их и передавать обратно клиенту.

Я также расширил проверку IP, чтобы проверить, является ли IP-адрес сеанса Либо: IP-адрес клиента для текущего запроса ИЛИ - IP-адрес моего сайта Work1, а запрос HTTPS имеет заголовок MySite-OriginalIp (который присоединен ко всем моим CURL запросы) и что это значение соответствует сеансу.

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

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