Обмен информацией между форумом vBulletin и платформой микроблогов status.net - PullRequest
Новая
       27

Обмен информацией между форумом vBulletin и платформой микроблогов status.net

0 голосов
/ 25 мая 2010

Мне нужно интегрировать vBulletin 4.0.3 Publishing Suite с платформой микроблогов status.net. Первое, что мне нужно сделать, это заставить эти 2 разделить 1 сеанс, чтобы пользователь, вошедший в форумы vBulletin, также входил на status.net и наоборот.

Я установил разные компоненты vBulletin в разных поддоменах:

  1. forums.sample.com - форумы форума
  2. blogs.sample.com - блоги vBulletin
  3. sample.com - управление контентом vBulletin

Все они указывают на одно и то же место (... / public_html / index.php), которое включает соответствующий файл php (content.php для sample.com | blog.php для blogs.sample.com | forum.php для forums.sample.com) в зависимости от $ _SERVER ['HTTP_HOST']

Я настроил vBulletin для использования одного cookie.domain (.sample.com) для всех этих 3 доменов, чтобы посещение разных доменов не прерывало сеанс.

У меня также есть status.sample.com, который является поддоменом, где установлен status.net. Конфигурация поддоменов отличается, поэтому document_root на самом деле является подпапкой (... / public_html / status /) в sample.com

Теперь, не могли бы вы дать мне несколько советов о том, как сделать так, чтобы все эти субдомены совместно использовали одну сессию?

Я не уверен, что это помогает, но, как я понимаю, status.net не выполняет пользовательскую обработку сеансов по умолчанию, но возможно включить ее, чтобы она начала хранить данные сеанса в таблице базы данных, называемой "сеанс". ». vBulletin сохраняет сессии в базе данных по умолчанию.

Любые советы будут оценены.

Спасибо.

1 Ответ

1 голос
/ 25 мая 2010

Даже если они оба разделяют сессию, это бесполезно для вас. Они должны использовать сеанс таким же образом, что означает:

  • Храните одинаковые переменные с одинаковыми ключами (или каждое приложение, запущенное в сеансе, кроме данных, которые ему нужны, данные, которые нужны другому).
  • Если они не используют одни и те же данные для входа в систему, они оба должны иметь доступ к имени пользователя / определениям / тому, что хранится в сеансе другого приложения
  • Если бы они хранили объекты, оба должны иметь доступ к определениям соответствующих классов

Итак, если вы не создаете свои собственные приложения и не думаете об этом с самого начала, забудьте о «обмене сессиями». Вместо этого используйте единый вход, например CAS или OpenID .

...