Darkmind
SNMP maniac
- Регистрация
- 31 Май 2006
- Сообщения
- 185
- Реакции
- 82
- Автор темы
- #1
Делаю кросспост своего сообщения с официального форума - тема полезная, а на оф.форуме сидят не все. Мало ли кому пригодится.
.
Invision Power Board умеет авторизовываться на внешних базах. Поэтому если в основу положить установленный Datalife, то прикручивая к нему форум возможно сделать так, чтобы форум авторизовывался из базы DLE.
Такая интеграция имеет некоторые преимущества: мы не влезаем в исходники DLE, подключаем интеграцию за пару минут и все будет работать на разных доменах.
.
Недостатки (если считать их таковыми) - логиниться надо на обоих сайтах порознь и пользовательские данные (личные сообщения, профили и т.п.) не синхронизируются.
.
Если недостатки критичны - используйте платные полные интеграции, этот гайд о подключении только внешней авторизации для IPB.
.
Теперь авторизовываясь в IPB, форум сползает в DLE'шную базу, попробует выцепить оттуда пользователя и пароль. Если пользователь найден и пароль введён правильно, IPB создаёт копию этого пользователя в своей базе. После этого таблицы пользователей будут работать параллельно с точки зрения IPB. Т.е. если пользователь после первого логина в IPB, сменит пароль в DLE, он сможет авторизовываться в IPB под любым из двух паролей.
.
Для любопытствующих, поясню зачем столько правок - причина в различных кодировках баз и страниц. Например, хэш слова "пароль" будучи представленным в UTF8 будет отличаться от того же слова "пароль" в windows-1251. Поэтому делается iconv(). По этой же причине мы вынуждены врезаться в файлы IPB исправляя strlen на mb_strlen (multibyte-функция) и добавляя флаг /u в функцию preg_match, которая по-умолчанию не умеет работать с unicode.
.
Invision Power Board умеет авторизовываться на внешних базах. Поэтому если в основу положить установленный Datalife, то прикручивая к нему форум возможно сделать так, чтобы форум авторизовывался из базы DLE.
Такая интеграция имеет некоторые преимущества: мы не влезаем в исходники DLE, подключаем интеграцию за пару минут и все будет работать на разных доменах.
.
Недостатки (если считать их таковыми) - логиниться надо на обоих сайтах порознь и пользовательские данные (личные сообщения, профили и т.п.) не синхронизируются.
.
Если недостатки критичны - используйте платные полные интеграции, этот гайд о подключении только внешней авторизации для IPB.
.
- Устанавливаем IPB
.
По-умолчанию IPB ставится в UTF-8 кодировке. Так и делаем, заранее подготавливая базу для работы с юникодом. Дальнейшие инструкции рассчитаны на то, что IPB установлен в UTF-8, а DLE на windows-1251. Для UTF-версий Datalife этот метод не тестировался.
. - Настраиваем модуль внешней авторизации в IPB
.- В System -> Tools & Settings -> Log In Management включаем External Database
- Там же нажимаем иконку Edit Details... и в Log In User Register URL вписываем адрес регистрации DLE (site.ru/index.php?do=register)
- Сохраняем изменения и нажимаем иконку Configure Details.... Вносим правки:
- Хост, порт, название базы, имя юзера и пароль для коннекта к базе
- Remote Database Table Name = users
- Remote Database Table Prefix = ваш префикс для таблиц (например, dle_) с подчёркиванием
- Remote Database Username Field = name
- Remote Database Password Field = password
- Password Hashing Technique = MD5
- Редактируем файл IPB admin\sources\loginauth\external\auth.php
.
Находим:
$check_pass = $password;
После добавляем строку:
$password = iconv("UTF-8","cp1251",$password);
.
Находим:
$check_pass = md5($password);
Меняем на:
$check_pass = md5(md5($password));
.
Находим:
$remote_member = $RDB->buildAndFetch( array( 'select' => '*',
Перед добавляем строку:
$username1251 = iconv("UTF-8", "cp1251", $username);
.
Находим:
'where' => REMOTE_FIELD_NAME."='".$RDB->addSlashes($username)."' ".REMOTE_EXTRA_QUERY ) );
Меняем на:
'where' => REMOTE_FIELD_NAME."=_cp1251'".$RDB->addSlashes($username1251)."' ".REMOTE_EXTRA_QUERY ) );
.
Находим:
$this->member_data = $this->createLocalMember( array( 'members' => array( 'name' => $username, 'password' => $password, 'email' => $email_address ) ) );
Меняем на:
$this->member_data = $this->createLocalMember( array( 'members' => array( 'name' => $username, 'password' => $password, 'email' => $remote_member['email'] ) ) );
.
. - Исправляем недочёты в IPB, редактируем файл admin\sources\classes\member\memberFunctions.php
.
Находим:
if( !preg_match( "/^[" . $check_against . "]+$/i", $_name ) )
Меняем на:
if( !preg_match( "/^[" . $check_against . "]+$/ui", $_name ) )
. - Исправляем недочёты в IPB, редактируем файл admin\applications\core\modules_public\ajax\register.php
.
Перекодируем файл в UTF-8
.
Находим:
$name = strtolower( trim( rawurldecode( $_POST['name'] ) ) );
Меняем на:
$name = mb_strtolower( trim( rawurldecode( $_POST['name'] ) ) );
Теперь авторизовываясь в IPB, форум сползает в DLE'шную базу, попробует выцепить оттуда пользователя и пароль. Если пользователь найден и пароль введён правильно, IPB создаёт копию этого пользователя в своей базе. После этого таблицы пользователей будут работать параллельно с точки зрения IPB. Т.е. если пользователь после первого логина в IPB, сменит пароль в DLE, он сможет авторизовываться в IPB под любым из двух паролей.
.
Для любопытствующих, поясню зачем столько правок - причина в различных кодировках баз и страниц. Например, хэш слова "пароль" будучи представленным в UTF8 будет отличаться от того же слова "пароль" в windows-1251. Поэтому делается iconv(). По этой же причине мы вынуждены врезаться в файлы IPB исправляя strlen на mb_strlen (multibyte-функция) и добавляя флаг /u в функцию preg_match, которая по-умолчанию не умеет работать с unicode.