Единая авторизация

Hungry_Hunter, Понимаю, но иначе не представляю как это сделать? Если ничего выше не подходит?

Не знаю, как для вебпрограммистов, но с точки зрения программиста в задаче нет принципиальных трудностей непосредственно в конструировании.
Но перед тем надо честно ответить на несколько вопросов, типа: на разных сайтах уже есть базы пользователей,
как их сливать? Как должна себя вести система сайтов при разных вариантах взаимной недоступности?
А инструменты - ну, например, PostgreSQL с межбазовыми запросами, или master-slave конфигурации, разные виды переноса данных...
Но это только средства, надо сначала детально проработать логику взаимной зависимости.
Если есть желание пригласить, могу посоучаствовать, аналогичный опыт есть.

AlexsimA, спасибо за идею, но к сожалению это не подходит.

babolo, как вы мило противопоставили программистов веб программистам - сказка просто.

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

Минимальное количестов изменений в коде и решение задачи.

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

Цитата ("babolo"):

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

а для чего? Как раз для консультацию. Я знаю как реализовать оба способа. Так же знаю как реализовать предложенный frig-ом способ. Я просто хочу выбрать лучший метод. Вот для этого и интересно мнение других.

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

WebDesignStudio Приношу извинения, я виноват.
В почте прочитал "спасибо за идею, но к сожалению это не подходит", решил,
что это ко мне, это мое первое тут выступление, не разобрался.
Мне лучше удалить? или с этим постом оставить?

WebDesignStudio Мое личное мнение - для разных вариантов составить сценарии, как оно будет
себя вести при разных видах отказов (связь и сервера), отсеять явно неинтересное, с остальным
идти к заказчику, подробно озвучить варианты, что бы он выбрал и подписал один из вариантов.
При доведении до заказчика внимательно следить, что варианты до сознания заказчика доходят,
и обставить процедуру выбора так, что бы он потом не смог накатить бочку на Вас.
Последнее может оказаться важнее выбора, правильного с Вашей точки зрения.

Цитата ("babolo"):

что бы он потом не смог накатить бочку на Вас

это не моя цель. Я хочу делать что бы все работало отлично.

WebDesignStudio Речь, прежде всего, не совсем о защите, а о том, что если клиент
сознательно выбрал не то, что Вы считаете оптимальным, то, если Вас интересует больше,
чем отхватить деньги и скрыться, то Вам предстоит медитировать над этим решением,
что бы осознать, что Вы понимаете неправильно и почему заказчик решил именно так.
Иначе есть риск, что бочку свою Вы получите вполне заслуженно.
А что бы не забыть, над чем медитировать, бумажка нужна.
Поскольку число глупых вопросов, которые можно задать заказчику, ограничено.

Цитата ("WebDesignStudio"):

Я хочу делать что бы все работало отлично.

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

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

frig Излишние ли сущности, со стороны, не зная, чего в точности хочет заказчик, определить невозможно.
Если заказчику, кровь из носу, надо, что бы сервера были работоспособны локально (а я легко могу представить
такую потребность), то, увы, надо делать распределенную. Хотя приятнее, конечно, делать по крайней мере
эту часть общей.
Еще раз перечитал свой первый пост (Вы о нем?), ну фиг знает... вроде никого не пинаю, а разница между
ними (нами?) таки есть. Не обязательно четкая граница.

Цитата ("babolo"):

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

Заказчик обычно хочет одного. Чтобы работало, чтобы было подешевле в обслуживании, подешевле в апгрейде и чтобы поменьше проблем. Ему не нужны ни сложности ни красивости зачастую. В большинстве случаев заказчику даже все равно что там как написано и как вообще работает. Главное - результат.

Цитата ("babolo"):

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

Это не гугль и не яндекс, чтобы там были такие требования. Так как они не были озвучены - я практически уверен, что их нет. WebDesignStudio наверняка единственный разработчик (если не ошибаюсь он давно и с самого начала разрабатывает этот проект) и именно он принимает подавляющее большинство (если не все) технические решения. Ну или спрашивает на форуме подсказки . Так что ИМХО это его затея и затея, на мой взгляд, не верная.
Цитата ("babolo"):

ну фиг знает... вроде никого не пинаю

Может это я слишком мнительный. Всякое бывает.

Цитата ("frig"):

наверняка единственный разработчик

ага
Цитата ("frig"):

и именно он принимает подавляющее большинство (если не все) технические решения

технические да. Как было замечено Цитата ("frig"):

или спрашивает на форуме подсказки

. То в чем я не уверен не делаю, а копаюсь, пока не нахожу лучший(или по крайней мере хороший) способ решения проблем.
Цитата ("frig"):

Так что ИМХО это его затея и затея, на мой взгляд, не верная.

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

Цитата ("WebDesignStudio"):

Идея была у заказчика, сделать единый юзер на всю сеть.

Да я не про юзера на всю сеть, а про разнесение по серверам.

Цитата ("frig"):

Да я не про юзера на всю сеть, а про разнесение по серверам.

ДА, от этого возможно и откажемся. А когда дойдет до такой посещаемости что сервер не выдержит, думаю я буду готов решить проблему. Пока знаю все только теоретически, на практике не делал(имею ввиду то о чем тут обсудилось про распределение рессурсов, балансировку)

Цитата ("WebDesignStudio"):

А когда дойдет до такой посещаемости что сервер не выдержит

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

frig, сайта пока работаю отлично. Проблем нет никаких. Но я люблю решать проблемы до их появления

Если заказчик согласится на то, что во время недоступности единого сервера нельзя будет
зарегистрироваться новому клиенту и оплатить что нибуть (принять оплату можно),
то единый сервер на авторизацию и деньги. Смягчить последствия недоступности
единого сервера можно при помощи копий по регистрации - задержкой регистрации,
с возможностью присылки письма на адрес регистрации типа "увы, проверка показала,
выбранный Вами логин не уникален, предлагаем повторить попытку с логинами типа
логин5, логин125, логинХХХ" и дележкой денег между серверами, то есть единая сумма
делится на части, в пределах локально хранящейся можно потратить сразу, а если больше,
то через сбор со всех баз. Распределение сумм можно оптимизировать.
Но это, естественно, геморойнее, чем просто единая база на едином сервере.
frig "Чтобы работало" - вот в этом то черти и водятся. Если сервер авторизации в России,
а локальный сервер в Казахстане, то как относиться к очередному трактористу на бульдозере
поперек кабеля? Если чтоб все равно работало, тогда хотя бы частично реплицировать,
соответственно требуемому в этой ситуации сохранению работоспособности.
Стоит ли - кто платит, тот и заказывает. Наше дело предоставить варианты и понять,
чего на самом деле хочет заказчик.