Можно ли реализовать подключение к бд в зависимости от пары логина и пароля?
Добрый день. Можно ли реализовать подключение и вывод нескольких одинаковых по структуре бд, но на двух серверах, через, к примеру, drupal, так, чтобы при подключении надо было ввести пару логин и пароль и система сама отслеживала, к какой бд надо подключаться.
не совсем так поняли меня, видимо я не так спрашиваю))
Есть несколько бд, которые используются разными источниками (сайт1 -> бд1, сайт2 -> бд2, и т.д.)
Требуется именно маршрутизатор на уровне входа на страницу с выводом таблицы одной бд после ввода определенной паре логин пароль.
Т.е. человек вводит логин - user1, пароль - fordb1 и попадает на бд1, а если вводит user2, fordb2 - попадает на бд2 (соответственно ему выдаются и другие результаты)
DoubleWish: если у вас сайт1 и сайт2 разные приложения/домены/ip. то тогда каким образом если вы зайдете на сайт1 и введете user2 вас должно перебрасывать на сайт2 ?
у вас на уровне приложения/сайта уже разделение есть - поэтому куда юзер зашел, на сайт1 или сайт2 - туда и будет подключаться.
еще раз объясните, можно ли на сайте1 ввести user2, а на сайте2 - user1 соответственно. такое возможно?
NYMEZIDE Мы вводим не на сайте1 или сайте2 эти данные. Мы их можем вводить на стороннем сайте вообще, а процесс подключения сортировал к какой бд надо подключаться по определенному адресу и там уже вводить пароль.
грубо говоря - мы вводим пару логин-пароль на стороннем сайте, который и должен нам вывести таблицу данных бд - а он видит, что мы ввели user1 и кидает нас по "адресу такому-то" и применяет там логин и пароль бд. Затем просто выводит внешний таблицы бд и усе ;)
DoubleWish: тогда вы выбрали неправильный путь изначально. создали сайты 1 и сайты 2. еще и БД создали под них. а если появиться еще одна роль/категория пользователей - создадите еще одну БД ?
по хорошему это делается так:
1. создается ОДИН сайт/приложение. в нем храниться конфиг файл к ОДНОЙ базе данных.
2. в БД, в ее логике, идет формирование запросов относительно юзера. разделение данных.
Плюсы:
- удобство поддержки. если поменяется структура - то менять нужно будет только в одной базе данных, а не в ее копиях.
- данные записывать точно также, делается привязка к пользователю на уровне БД.
неправильная архитектура - если вы делите физически данные на разные сервера, а не логически на уровне одной БД.
NYMEZIDE Ну... логика у вас не очень правильная. Для наших целей нужен сайт не один. Если будет один сайт - смысл вообще этого тогда всего.
Вы не понимаете сути. Нам нужен просто вывод данных бд в зависимости от того, что вписали в строчку логин-пароль, и всего-то. А не один сайт с одной бд. Там сайтов вообще 12 штук, и баз данных столько же, и все они содержат разные данные, НО структурированы одинаковы (столбцы везде одинаковые, данные строк - разные).
И что значит "создали сайты 1 и сайты 2. еще и БД создали под них. а если появиться еще одна роль/категория пользователей - создадите еще одну БД ?" - у каждого пользователя будут свои права на редактирование бд, зачем создавать ещё одну бд. Или ваша логика исходит из того, что БД все таки должна быть одна?)))) Ну тогда вы просто не понимаете, что я имею ввиду.
DoubleWish: хорошо, допустим вы разделили данные физически на разные сервера.
ОК.
тогда делаете все так:
1. создается одно приложение/сайт.
2. форма логина содержит выпадающий список ваших двенадцати БД. а также логин и пароль.
3. сайт тупо выбирает из конфига ту БД, которую выбрали в выпадающем списке и делает коннект к БД по логину и паролю.
все просто и удобно.
а если сделать логику в приложении, которая тупо перебирает Логин Пароль по всем двенадцати БД - то это дурдом. Человеку нужно запомнить 12 логинов и 12 паролей, чтобы подключаться к вашим разным БД.
DoubleWish: вот честно, дурдом у вас. неправильное понимание проектирования и создания БД.
обслуживать 12 баз данных - тупо из-за того, кто кто-то не потрудился сделать роли и права в одной БД.
добавить новую таблицу или изменить существующую - это накатить изменения на все 12 штук. идиотизм.
NYMEZIDE: самому старому сайту 12 лет, самому новому - 2 года, все они в топе по seo и смысла сейчас сливать базы нет, потому что структурно они не отличаются, кроме как пары подпунктов (Т.е. у всех, к примеру, есть графа "имя", "текст", но не у всех есть пункт "бонус") . В единую базу, все же, сливать не решимся. Тем более грузится сервер 100% начнет больше.
1. данные территориально разделены. базы данных в разных городах. ОК, тогда разделять на 12 штук имеет смысл.
в таком случае вы делаете выпадающий список с городами - и все счастливы. не надо городить костыли в виде общей БД, которая хранит данные подключения ко всем.
2. данные разделены по правам/ролям - тогда создавать 12 штук не надо. достаточно сделать правильный запрос с учетом ролей и прав. и будет выводиться юзеру1 одни данные, а юзеру2 другие.
DoubleWish: есть такая штука - называется составной первичный ключ. через него можно сделать разделение данных. никаких коллапсов не будет. но это все надо делать еще на этапе создания.
а у вас я так понял уже давно все создано. и пути назад нет. надо выкручиваться.
DoubleWish: по хорошему если БД разные - делают разные точки доступа (сайты или приложения) и объединяют только систему авторизации. чтобы она была единая, но перенаправление делается на конкретный сайт в зависимости от логина и пароля.
"все они в топе по seo и смысла сейчас сливать базы нет"
получается существует еще и 12 разных сайтов для каждой базы?
"по хорошему если БД разные - делают разные точки доступа (сайты или приложения) и объединяют только систему авторизации. чтобы она была единая, но перенаправление делается на конкретный сайт в зависимости от логина и пароля." - так это то, что как раз и нужно
DoubleWish: наконецто я стал понимать всю архитектуру.
тогда задача сводиться к следующему:
1. поднять 13 сайт с локальной БД, структуру я уже писал комментарием ниже, где Юзеры и Серверы.
2. всем людям раздать адрес 13 сайта.
3. логика 13 сайта будет сводиться к перенаправлению на конкретный сайт с конкретной БД.
но вам все равно не уйти от создания своего OAuth или OAuth и внедрения его на каждом сайте. если хотите чтобы автоматом его авторизовывало на конкретном сайте.
NYMEZIDE: ты зря сдался. После ключевых слов " все они содержат разные данные, НО структурированы одинаковы (столбцы везде одинаковые, данные строк - разные)" можно было прекращать разговор - клиент не понимает, что делает. Он и 120 сайтов таким промышленным методом нагенерит. Надо слушать не его лепет, а читать описание. Которое по сути единый сайт с множеством пользователей и есть. При ответах всегда должна быть презумпция тупости: если человек задает тупой вопрос, то, скорее всего, это от неграмотности, а не от реальной потребности. И надо не помогать ему вырезать гланды через ж автогеном, а тупо бить по голове (потому что объяснения не помогают), пока не поймет, что у него изначальная схема кривая.
FanatPHP: обиженка? Дурачек, уже нашли решение, БД все в одну сливаем и делаем доступ по пользователям. Спасибо NYMEZIDE за помощь, а тебе - не хворать.
FanatPHP: я не вкурсе контекста создания баз данных. может это разные абсолютно клиенты. а автор хочет сделать OpenID или OAuth для них всех.
скорее всего 12 баз данных - это 12 интернет-магазинов. по 12 разным категориям товаров или для 12 клиентов. но тогда зачем дугим клиентам знать про другие 11 сайтов помимо себя? зачем объядинять единую точку входа? много вопросов, а автор не хочет идти на встречу.
NYMEZIDE: дело в том, что не мы не хотим, а люди, которым это делается. Не хотят ввиду особенностей администрирования бд, сложившихся для них за 8 лет. И там интернет-каталоги, по 3000-20000 объявлений в каждой. А объединять надо для сторонних администраторов, которых будут привлекать для внесения данных на аутсорсе :)
FanatPHP: вы не помогли никак решить проблему, говорите несуразный бред и не даете никаких рекомендаций. Какой от вас толк? Может просто покинете беседу? Если вам не интересно - проходите мимо.
NYMEZIDE: ну вот теперь ты начинаешь нести чушь. Откуда 11 клиентов узнают про первого, если им про него специально не рассказать? Есть тыщи сайтов, которые работают по такой (единственно логичной) схеме. К ним у тебя тоже много вопросов? Те же социальные сети, будь они неладны. По-твоему, они тоже должны создавать по сайту на каждого юзера? И какая проблема с единой точкой входа? Если человек заходит через неё на свой сайт, то откуда он узнает, что есть ещё 11?
FanatPHP: Не ты помог решить эту проблему, поэтому покинь обсуждение. Если он несет чушь и помог решить конкретную проблему... наверное, его познания намного больше твоих?
И судя по вопросам, которые вы дальше продолжаете строчить - вы так не поняли вообще ничего.
DoubleWish: Твоя нелогичность очень забавна :) И это ЕЩЁ одно подтверждение моей правоты (хотя подтверждений никаких не требуется - тут всё как на ладони)
DoubleWish: ну тогда вам надо почитать про реализацию OAuth. И сделать межсайтовую авторизацию.
просто поймите суть еще одну - если пользоватерю надо будет на другой сайт (из тех 12) - он сам пойдет на другой сайт. Или выберет его из выпадающего списка.
А обмануть юзера, мол вводи логин и пароль - а мы тебя кинем туда куда-нужно - не сработает. в втроке браузера все равно будет отображаться конкретный сайт.
или делать один сайт общий (13й) и создавать DbContext на этапе авторизации, который будет иметь подключение к кокретной БД. но тогда логику отображения данных надо делать под все 12 сайтов.
Ну вот, ты снова переходишь на личности. Ты это уже делал, и успеха добился весьма жалкого. Попробуй немного подумать перед тем, как писать следующую реплику. И надо ли тебе её писать вообще ;-)
Я понял! Вы хотите общую админку сделать для 12 сайтов?
ну тогда просто создавайте mysql_connect после ввода логина и пароля, через локальную БД определайте к кому подключаться. вот только все равно придеться создавать множество юзеров на всех БД - иначе не пустит. или работать чисто по мастер паролю, универсальному на все базы.
FanatPHP я просил вас покинуть обсуждение уже не раз. Вы глухой, слепой или сверхгордый человек, который считает себя выше остальных. Я ещё раз прошу - покиньте обсуждение, от вас здесь толка НЕТ.
NYMEZIDE админка всех бд, это да. Мастерпароль не подойдет, а вот множетсво юзеров, скорее всего, это да. Там тогда на 12 баз минимум сразу будет 36, хотя не критично )
DoubleWish: Ты многого в этой жизни ещё не понимаешь. К примеру, если ты не хочешь с кем-то общаться, то не надо ему назойливо об этом сообщать. Надо просто не общаться ;)
Ну что ж - тогда продолжим! То есть, чтобы показать свою культурность, ты демонстрируешь свой детсадовский лексикон? :) Ну что ж - логичность в этом примерно такая же, как в необходимости oauth для общей админки :)
Заведите ещё одну БД :) В которой храните связку логин-пароль, имя БД и адрес MySQL сервера. Далее сверяйте введённые данные пользователем с данными в этой таблице и подключайте скрипт на БД, соответствующей извлечённым данным.
DoubleWish:
1. создаете новую БД. в ней создаете таблицу Серверы (serverID, Servername, DbName, IP и т.д.) и таблицу Юзеры (userID, login, password, serverID)
2. в приложении делается коннект к этой общей БД на мастер логину и паролю. который делает запрос к таблице Юзеры, если логин и пароль нашлись - возвращает запись из таблицы Серверы и получает соответстующие данные для подключения.
3. Затем программно делается подключение к БД, но уже с логином и паролем пользователя и подстановкой строки подключения из таблицы Серверы.
Есть несколько бд, которые используются разными источниками (сайт1 -> бд1, сайт2 -> бд2, и т.д.)
Сдается мне аффтар, что ты фантазируешь. То у тебя сайты, а потом уже вдруг таблицы.
Разумеется, такая система нежизнеспособна, и я сильно сомневаюсь, что она существует в реальности. Поэтому лучше бы тебе отказаться от этой фантазии и делать по-человечески.
Вы, наверное, читать не умеете. Сайты тут не причем, это я поясняю, от чего конкретно, базы данных. И то, что есть эти сайты - тут не при чем. Меня интересует администрирование БД, а не сайтов.