Единая регистрация и авторизация на нескольких сайтах

[cyxap 0]

Здравствуйте, Celsoft!

Пишу под впечатлением данной новости, о Единой регистрации и авторизации на нескольких сайтах:

http://dle-news.ru/2007/04/18/edinaja_registracija_i_avtorizacija_na_neskolkikh_sajjtakh.html

Мануал читал, ответа не нашел, поэтому задаю вопрос здесь.

Ситуация следующая. Есть 2 (а в скором будущем будет 3 или 4) независимых ресурса на DLE, все с лицензиями.

Во всех ресурсах есть зарегистрированные пользователи. На этих ресурсах, в таблице dle_users есть дополнительные колонки, которые были созданы сторонними модулями.

Задача - объединить базы пользователей в одну, общую, чтобы авторизация и регистрация была единой.

Вопросы:

1. Возможно ли объединить существующие таблицы пользователей без потери данных и сохранение всех колонок баз?

2. Не исключено, что и там, и там есть юзеры, у которых указано одно и то же мыло, ник и т.п.. Как убрать дубликаты?

3. А если это не дубликаты, а разные люди, но с одинаковыми никами, то таких юзеров из одной базы придется удалять?

4. Как будет осуществляться загрузка и отображение например, тех же аватаров? Юзеру надо будет загрузить их на каждый сайт отдельно? И на каждом сайте они будут отображаться свои? Или этот вопрос не решен?

5. Какие поля будут находиться в "общей базе пользователей"? И какая таблица отвечает за эту базу - только dle_users или еще какие-то?

6. Как технически осуществлять перевод всех сайтов на общую базу пользователей?

Я вижу это так:

- в каждой существующей базе сменить префиксы на dle1_, dle2_, в одной, главной можно оставить dle_;

- перенести содержимое всех таблиц на один хост, в одну базу данных - и получаем все базы трех сайтов в одном месте, но с разными префиксами;

- указываем в dbconfig.php соответствующих сайтов параметры подключения к новой базе и новые префиксы, но ставим везде один и тот же USERPREFIX. всё.

7. Описанных в п.6 действий достаточно или где-то что-то возможно понадобиться еще руками править? Все данные касательно подключения к базе DLE берет из dbconfig.php? А теоретически, могут ли сторонние модули обращаться к базе в обход этого файла? Или все проходит через него и изменений в нем достаточно?

Спасибо.

P.S. Адрес сайта(-ов) пришлю в личку по требованию.

Изменено 7 октября 2009 пользователем cyxap

[celsoft 6 076]

1. Возможно ли объединить существующие таблицы пользователей без потери данных и сохранение всех колонок баз?

зависит от сторонних модулей, если они делают запросы с правильными префиксами из настроек, то нет никаких проблем

2. Не исключено, что и там, и там есть юзеры, у которых указано одно и то же мыло, ник и т.п.. Как убрать дубликаты?

3. А если это не дубликаты, а разные люди, но с одинаковыми никами, то таких юзеров из одной базы придется удалять?

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

4. Как будет осуществляться загрузка и отображение например, тех же аватаров? Юзеру надо будет загрузить их на каждый сайт отдельно? И на каждом сайте они будут отображаться свои? Или этот вопрос не решен?

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

5. Какие поля будут находиться в "общей базе пользователей"? И какая таблица отвечает за эту базу - только dle_users или еще какие-то?

много каких, все что связано с пользователями

6. Как технически осуществлять перевод всех сайтов на общую базу пользователей?

Я вижу это так:

- в каждой существующей базе сменить префиксы на dle1_, dle2_, в одной, главной можно оставить dle_;

- перенести содержимое всех таблиц на один хост, в одну базу данных - и получаем все базы трех сайтов в одном месте, но с разными префиксами;

- указываем в dbconfig.php соответствующих сайтов параметры подключения к новой базе и новые префиксы, но ставим везде один и тот же USERPREFIX. всё.

совершенно верно

А теоретически, могут ли сторонние модули обращаться к базе в обход этого файла?

могут, все зависит от модуля, если модуль правильный, то он пользуется настройками, если нет, то нет.

[cyxap 0]

Благодарю за подробный ответ. Позвольте несколько уточнений.

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

У меня на одном проекте около 4 тыс. человек, на другом пока всего 200. Т.е. на свежем проекте я смогу найти одинаковые email'ы и руками удалить дубликаты юзеров. Но вопрос был чуть-чуть о другом - после удаления дубликатов юзеров, как совместить имеющиеся таблицы пользователей? И какие вообще таблицы совмещать кроме _users?

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

Заглянул в базу, таблица _users - там к аватарам ведут относительные ссылки, даже не ссылки, а именно названия файлов, т.е. foto_123.jpg. Соответственно, если юзер на www.site1.com загружает одну, она получает название foto_123.jpg и это прописывается в таблицу. Далее, он идет на www.site2.com, там загружает аватарку, она получает имя foto321.jpg и это прописывается в таблицу. Таким образом, если я правильно понимаю, на www.site1.com аватарка уже не будет видна. Или будет видна чужая аватарка с именем foto321.jpg. Я правильно понял?

Если правильно, то можно сделать, чтобы путь к аватаркам был абсолютный и хранились бы они все на 1 домене? Или каким-нибудь другим образом решить этот вопрос?

много каких, все что связано с пользователями

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

Спасибо.

Изменено 7 октября 2009 пользователем cyxap

[celsoft 6 076]

У меня на одном проекте около 4 тыс. человек, на другом пока всего 200. Т.е. на свежем проекте я смогу найти одинаковые email'ы и руками удалить дубликаты юзеров. Но вопрос был чуть-чуть о другом - после удаления дубликатов юзеров, как совместить имеющиеся таблицы пользователей? И какие вообще таблицы совмещать кроме _users?

Я незнаю как ответить на этот вопрос, кнопки совместить таблицы не существует. Поэтому нужно писать скрипт конвертер, который будет брать данные из одной таблицы, проверять уникальность и вставлять в другую таблицу. Стандартно таких конвертеров в скрипте нет.

Заглянул в базу, таблица _users - там к аватарам ведут относительные ссылки, даже не ссылки, а именно названия файлов, т.е. foto_123.jpg. Соответственно, если юзер на www.site1.com загружает одну, она получает название foto_123.jpg и это прописывается в таблицу. Далее, он идет на www.site2.com, там загружает аватарку, она получает имя foto321.jpg и это прописывается в таблицу. Таким образом, если я правильно понимаю, на www.site1.com аватарка уже не будет видна. Или будет видна чужая аватарка с именем foto321.jpg. Я правильно понял?

Если правильно, то можно сделать, чтобы путь к аватаркам был абсолютный и хранились бы они все на 1 домене? Или каким-нибудь другим образом решить этот вопрос?

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

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

Это вопрос технической поддержки скрипта, поэтому по данному вопросу в службу поддержки скрипта http://dle-news.ru/index.php?do=feedback со своего клиентского аккаунта, также необходимо наличие лицензии, которая включает в себя службу поддержки, если у вас такая лицензия, то вам сообщат список таблиц. Если лицензия без поддержки, то искать придется самостоятельно.

[cyxap 0]

Отписался в фидбэк.

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

Я понимаю, что для отображения он физически должен быть на сервере, однако, закачав его на один домен, он ведь автоматически не появится на всех остальных доменах? Или как?

Еще раз объясню вопрос:

Пользователь заходит на site1.com, загружает туда картинку, имя этой картинки прописывается в базе. И эта картинка отображается в его профиле на сайте www.site1.com в качестве аватара.

Но в профиле этого же пользователя на site2.com эта картинка отображаться не будет, т.к. она была загружена только на site1.com, а на site2.com ее фактически нету. Или же картинка с этим именем есть, но принадлежит другому юзеру. Хотя база пользователей у обоих сайтов одна.

Или опять неправильно?

Если все-таки правильно, то я вижу 2 решения:

- чтобы путь к аватарке в базе прописывался в абсолютном виде (с указанием домена);

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

И еще назрел вопрос. Один сайт у меня чисто новостной - т.е. Журналисты могут без модерации публиковаться. На втором же сайте возможность публиковаться должна быть лишь у Главных Редакторов и Админов. Это можно будет сделать? Ведь это определяется не юзерами, а настройками каждой конкретной копии скрипта на каждом отдельном домене?

И аналогичный вопрос про группы. В таблице пользователей стоит только номер группы в виде числа, а название (Админ, Главред, Журналист, Посетитель и т.п.) и права групп определяются в каждой отдельной копии скрипта?

[celsoft 6 076]

Я понимаю, что для отображения он физически должен быть на сервере, однако, закачав его на один домен, он ведь автоматически не появится на всех остальных доменах? Или как?

нет не появиться, он появиться только на том сайте, где его загрузили.

Или же картинка с этим именем есть, но принадлежит другому юзеру.

у другого пользователя на другом домене не может быть аватара с таким же именем как у другого пользователя и на первом сервере. Такова система имен файлов, она уникальна для каждого пользователя, независимо от имени самого аватара. Поэтому пользователь может загрузить аватар на одном сайте и на другом, его место никто не займет.

И еще назрел вопрос. Один сайт у меня чисто новостной - т.е. Журналисты могут без модерации публиковаться. На втором же сайте возможность публиковаться должна быть лишь у Главных Редакторов и Админов. Это можно будет сделать?

нет, права становяться едины для всех сайтов

И аналогичный вопрос про группы. В таблице пользователей стоит только номер группы в виде числа, а название (Админ, Главред, Журналист, Посетитель и т.п.) и права групп определяются в каждой отдельной копии скрипта?

нет, права пользователей, и вообще все что касается пользователей в БД, становяться едиными для всех сайтов

[cyxap 0]

Такова система имен файлов, она уникальна для каждого пользователя, независимо от имени самого аватара.

Хорошо, с этим разобрались, +1.

Поэтому пользователь может загрузить аватар на одном сайте и на другом, его место никто не займет.

Так если пользователь загрузит 1 аватар на 1-м сайте, и другой аватар на 2-м сайте, то в базе будет 2 строчки по поводу его аватарки? А если будет третий сайт и третья аватарка, то будет 3 строчки?

Я, возможно, лезу в излишние технические подробности - это от того, что я считал, что скрипт просто тупо берет название файла "foto123.jpg" из таблицы, подставляет перед ним адрес "home.url/uploads/" и получается путь к аватарке. Если это не так, то хочу сказать, что технические подробности мне абсолютно не нужны.

Мне лишь важно, чтобы на всех 2-х, 3-х или 10-ти сайтах у пользователя отображалась бы одна и та же аватарка, либо та аватарка, которую он загрузил на каждом конкретном сайте. Если это так, скажите "да, это так" и мне этого будет достаточно.

нет, права пользователей, и вообще все что касается пользователей в БД, становяться едиными для всех сайтов

Вроде бы понял, но не до конца.

Вопрос №1: Где прописываются группы пользователей (ID и название)? Тоже в общей для трех сайтов таблице?

Вопрос №2: В Настройках групп пользователей существует возможность выбора Доступных и Доверительных разделов для конкретных групп пользователей. Разделы на всех 3 сайтах разные. Какие разделы будут отображаться на site1.com, site2.com, site3.com в админке при выборе Доступных и Доверительных разделов для групп? Разделы всех трех сайтов или каждого конкретного?

Вопрос №3: Иными словами, можно ли как-нибудь "Журналистам", которые свободно публикуются на site1.com, запретить писать в некоторые разделы на site2.com? Это основная задача.

[celsoft 6 076]

Так если пользователь загрузит 1 аватар на 1-м сайте, и другой аватар на 2-м сайте, то в базе будет 2 строчки по поводу его аватарки? А если будет третий сайт и третья аватарка, то будет 3 строчки?

имя файла аватара у пользователя одно и неизменно.

Я, возможно, лезу в излишние технические подробности - это от того, что я считал, что скрипт просто тупо берет название файла "foto123.jpg" из таблицы, подставляет перед ним адрес "home.url/uploads/" и получается путь к аватарке. Если это не так, то хочу сказать, что технические подробности мне абсолютно не нужны.

123 в названии это не "левые" цифры, это ID пользователя и у каждого пользователя оно одно на все времена и на на все сайты

Вопрос №1: Где прописываются группы пользователей (ID и название)? Тоже в общей для трех сайтов таблице?

в общей

Вопрос №2: В Настройках групп пользователей существует возможность выбора Доступных и Доверительных разделов для конкретных групп пользователей. Разделы на всех 3 сайтах разные. Какие разделы будут отображаться на site1.com, site2.com, site3.com в админке при выборе Доступных и Доверительных разделов для групп? Разделы всех трех сайтов или каждого конкретного?

они должны быть одинаковы если хотите использовать эту настройку в противном случае ее нельзя использовать

Вопрос №3: Иными словами, можно ли как-нибудь "Журналистам", которые свободно публикуются на site1.com, запретить писать в некоторые разделы на site2.com? Это основная задача.

Никак, права едины для всех сайтов. Назначить разные права разным сайтам при объеденении БД нельзя.

[cyxap 0]

Спасибо, по поводу аватара понял. Единственное уточнение - если юзер не загрузил на site2.com аватарку, у него будет отображаться заглушка (no-photo.gif)?

они должны быть одинаковы если хотите использовать эту настройку в противном случае ее нельзя использовать

Никак, права едины для всех сайтов. Назначить разные права разным сайтам при объеденении БД нельзя.

Спасибо. Но, поизучав базу, понял, что параметры доступа групп задаются таблицей, в которой разрешенные категории прописываются в одном столбце. И в этом столбце указаны именно ID категорий.

Я правильно понимаю, что создай я 5 категорий с ID# 601, 602, 603, 604 и 605 (номера этих ID точно уникальны для данного сайта и ни на каких других не повторяются) и пропиши я их в эту таблицу определенному юзеру (не прописывая остальным), моя проблема будет решена? Если да, то как наиболее цивильным путем создать такие категории с большими значениями ID?

Изменено 7 октября 2009 пользователем cyxap

[celsoft 6 076]

Спасибо. Но, поизучав базу, понял, что параметры доступа групп задаются таблицей, в которой разрешенные категории прописываются в одном столбце. И в этом столбце указаны именно ID категорий.

Я правильно понимаю, что создай я 5 категорий с ID# 601, 602, 603, 604 и 605 (номера этих ID точно уникальны для данного сайта и ни на каких других не повторяются) и пропиши я их в эту таблицу определенному юзеру (не прописывая остальным), моя проблема будет решена? Если да, то как наиболее цивильным путем создать такие категории с большими значениями ID?

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

Единственное уточнение - если юзер не загрузил на site2.com аватарку, у него будет отображаться заглушка (no-photo.gif)?

да

[cyxap 0]

никаким пользователям вы не можете какому то определенному пользователю прописывать какие либо настройки из настроек групп.

Не понял формулировки и продолжаю уточнять...

Поясните, пожалуйста, какие именно данные являются ОБЩИМИ для сайтов с единой регистрацией/авторизацией?

В статье речь шла о пользователях (я думал это только логин/пароль/личные данные). Сюда же, как я понял из личной переписки, следует отнести таблицы, отвечающие за ПС, восстановление паролей, бан, заметки в админке и (!) _usergroups.

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

Напомню задачу. Необходимо сделать так, чтобы на 3-м сайте, Журналисты не могли писать в определенные категории. А на двух других сайтах, чтобы Журналисты обладали обычными правами и могли публиковаться во всех разделах.

Выход я вижу в следующем: создаем 20 категорий, в которые Журналисты смогут писать без модерации (ID с 1 по 20). Далее создаем еще 10 категорий, в которые Журналисты писать не смогут (ID с 21 по 30). Создаем специальную группу пользователей "Супер-Журналисты" и задаем им права в Доверительных разделах - могут писать и в первые 20 категорий, и во вторые 10 категорий. Эти права распространяются на все сайты. А обычным Журналистам мы разрешаем писать только в первые 20 категорий.

На сайте, с этими вторыми 10 категориями, мы создаем все 30 категорий. Причем первые 20 оставляем без названия (ставим прочерки), а последним 10 даем нужные имена. Далее эти 30 категорий мы через Админку сортируем так, чтобы нужные 10 отображались в верху, а остальные - внизу. Это решает проблему отображения нужных 10 в самом верху при добавлении новостей.

На других же сайтах, где есть 20 основных категорий, и нету этих 10 особенных, мы просто тупо создаем категории, но ставим вместо названий прочерки.

Кривовато конечно, но, как я понимаю, другого выхода нету?

Правильно ли я теперь понял суть функционирования прав юзеров и категорий? Можно приступать к реализации на практике?

Правда перед реализацией этого "кривого" способа, хочу узнать - не планируете ли переделку структуры базы и таблиц для "прямой" реализации поставленной задачи? Иными словами, чтобы права доступа пользователей задавались бы не в общей таблице _usergroups, а в отдельной таблице для каждого сайта? А то будет обидно, если сделав все таким образом, потом структура базы будет изменена, и все мои труды окажутся напрасными.

P.S. Толком еще не разбирался с доступом разных групп в админку, но, как я понимаю, там все просто - в _usergroups надо в столбце admin_XXXX указать 1 или 0. Или сложнее?

P.P.S. И кстати, как быть с мультиязычностью? У меня в планах было создание 1 сайта на английском, второго на русском - с общей базой юзеров. Но ведь названия групп пользователей задаются в общей базе, так? - Единственное, что приходит в голову: убрать из userinfo.tpl тег выводящий группу, и вместо него вставить какой-то тег, заданный в website.lng или как-то через xfields. Это не до конца осмыслено.

Благодарю.

Или даже еще проще. На 3-м сайте создаем нужные категории, а потом в phpMyAdmin в таблице dle_category просто изменяем их ID на 301, 302, 303, 304 и так далее. Тогда у этих категорий значения ID будут уникальными по отношению к первому и второму сайтам.

Таким образом категории со значениями ID 301, 302, 303, 304 будут только на третьем сайте, и права "Супер Журналистам" будет задать проще простого.

[celsoft 6 076]

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

P.S. Толком еще не разбирался с доступом разных групп в админку, но, как я понимаю, там все просто - в _usergroups надо в столбце admin_XXXX указать 1 или 0. Или сложнее?

зачем вообще трогать БД напрямую, когда нужно посто в админпанели указать куда разрешен доступ, а куда нет.

[cyxap 0]

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

Поясните, пожалуйста, что значит должны быть одинаковы? Называться одинаково и иметь одни и те же новости? Или иметь один и тот же ID? Или что?

Если они одинаковы вы можете применять эти настройки в настройках групп, если они не одинаковы то не можете

И что означает не могу? Скрипт просто не будет работать? Или может быть, найдя в правах у юзеров категорию ID#500, и не найдя ее в dle_category, скрипт выдаст ошибку? Или как?

Ответьте все-таки, могу ли я пойти путем, описанным в сообщении №11 этой темы. И, раз вы говорите, что гарантий работоспособности этого способа нет, то сориентируйте хотя бы, в каком именно месте могут пойти глюки?

Изменено 8 октября 2009 пользователем cyxap

[celsoft 6 076]

Поясните, пожалуйста, что значит должны быть одинаковы? Называться одинаково и иметь одни и те же новости? Или иметь один и тот же ID? Или что?

иметь один и тот же ID, причем все категории.

И что означает не могу? Скрипт просто не будет работать?

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

Ответьте все-таки, могу ли я пойти путем, описанным в сообщении №11 этой темы.

Официально нет, т.к. скрипт на это изначально не расчитан. Поэтому на свой страх и риск, я не знаю какие проблемы у вас могут быть, какие нет. Я же вам уже много раз написал, настройки групп едины для всех сайтов, а вы опять спрашиваете могу ли я разделить настройки для одного сайта такие, для другого такие. Я еще раз вам отвечаю, нет не можете, скрипт на это не расчитан. Не расчитан, значит тестирование этого не проводилось, и разработчиками как возможность не предусматривалась.

[cyxap 0]

Я понял, спасибо, поиграюсь на локале, попробую совместить 3 базы и сделать, как описывал. Если хотите, отпишусь сюда по результатам.

Но остается в силе вопрос про русский-английский язык и вывод названий групп. Это мне придется реализовывать в любом случае, т.к. один из сайтов изначально планировался на двух языках. Разные шаблоны и языки для рус/англ не подходят, этот вариант рассматривался.

[cyxap 0]

Про русские-английские имена групп, кажется, догадываюсь, как сделать. В шаблоне вместо вывода статуса прописать:

[group=1]Administrator[/group] [group=2]Editor In Chief[/group] [group=3]Journalist[/group] и т.д.

Поправьте, если не так, и есть более разумный способ.

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

Всегда по порядку? (т.е., если у нас есть категории 1, 3 и 5, движок будет называть последующие 6, 7, 8 и т.д., а номера 2 и 4 останутся свободными)

Или же он всегда заполняет пустоты? (т.е. при наличии категорий 1, 3, 5, вновь созданные категории сначала получат ID 2 и 4, а только потом уже 6, 7, 8 и т.д.)

Изменено 8 октября 2009 пользователем cyxap

[celsoft 6 076]

Но остается в силе вопрос про русский-английский язык и вывод названий групп. Это мне придется реализовывать в любом случае, т.к. один из сайтов изначально планировался на двух языках. Разные шаблоны и языки для рус/англ не подходят, этот вариант рассматривался.

такой возможности нет.

Про русские-английские имена групп, кажется, догадываюсь, как сделать. В шаблоне вместо вывода статуса прописать:

[group=1]Administrator[/group] [group=2]Editor In Chief[/group] [group=3]Journalist[/group] и т.д.Поправьте, если не так, и есть более разумный способ.

неверно, тег [group=1]Administrator[/group] выводит текст с учетом группы того кто просматривает сайт, а не того чей профиль вы просматриваете

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

автоматически по порядку, но это уникальное значение и никогда не повторяетяся, например если у вас было ID 3 и вы его удалили, то следущее в любом случае будет 4, а не 3.