Просьба привести цитату где я предлагаю нечто подобное (хотя это технически несложно и давно реализовано в том же Оракле).
Обсуждаемый концепт реализован во множестве проектов «двухзвенок» с толстым клиентом, причем как концепт он обсуждался лет 20 назад.
Для данной архитектуры специфично то, что ей нужен именно пароль. Не хэш, не токен — только и исключительно пароль, причем пароль от пользователя в БД.
Хмм… Представим себе типовое хранение хешей паролей в БД, проверкой которых занимается соответствующий сервис, напрямую соединяющийся с БД. Пусть длина цепочки передачи пароля до сервиса равна N. Теперь совместим сервис с СУБД. Длина цепочки остается N.
Не забываем учесть необходимую дополнительную авторизацию самого сервиса в СУБД, получаем две цепочки уязвимости вместо одной.
Ваш опыт сомнению не подлежит, но я бы не хотел переходить от обсуждений концептов к их реализациям.
Замечание про дырки в цепочках TLS правильное, но, к сожалению, не специфичное для данной архитектуры. Вопрос неустойчивости SSO несколько субъективный, у меня был позитивный опыт (крупная supply chain система).
Полностью с вами согласен, что масштабирование пары СУБД+СП имеет больше степеней свободы, чем СУБД со встроенным СП. Но как выше уже заметили, клиенту нужны не степени, а «чтобы работало по надежному сценарию, пусть даже одному».
Разумеется, процедурное расширение SQL может показаться менее подходящим языком реализации бизнес-логики, тут есть и плюсы (встроенный интегрированный SQL, высокая производительность связанного с СУБД кода, отсутствие перегонки данных между процессами), так и минусы (как правило слабая организация модульности, СУБД vendor lock, отсутствие ООП, более сложное тестирование). Это все понятно, остается выбрать баланс соответствия конкретному случаю.
Зачем же гонять пароли открытым текстом? Веб-приложения давно умеют HTTPS. В любом случае, никакой специфики для данного случая здесь нет. Аналогично настраивается и SSO в Windows-сети.
Рассматривайте архитектуру, не как отсутствие сервера приложений (СП), а как реализацию сервера приложений средствами СУБД, тогда большинство вопросов отпадает. Вопрос про распределение нагрузки решается аналогичным образом, как и в случае выделенного СП.
Почему же не выйдет? Авторизацию можно по-прежнему продолжать использовать СУБД-шную, логин/пароль пробрасываются напрямую, сессия веб-приложения работает с установленным к СУБД соединением. Но возникает бонус — можно сделать и свою авторизацию поверх. Нужно ли это делать — отдельная тема.
Вопрос был «как сделать веб-клиент?», вроде бы я ответил. Как сделать веб-клиент без веб-сервера не совсем понимаю. Сюжет о разделении нагрузки — другой вопрос, опять-таки, не вижу, что там нужно дополнительно разделять по сравнению с исходной архитектурой. Бонусы появляются, да.
Впрочем, у меня есть более занятный вопрос: а как, собственно, сделать из nexus веб-приложение?
Технически это несложно: вместо тонкого rich-клиента пишется аналог на JS + web server. Вместо прямого использования SPID в протоколе поддерживается сессия и делается проброс контекста в слой бизнес логики (session id -> SPID), метод описан в книжке "СУБД для программиста"
P.S. к «минусованию» ваших комментариев никакого отношения не имею
Справедливости ради, продажи были, но их оказалось недостаточно.
Существовал (и вроде даже как-то дышит до сих пор) концептуальный аналог нашей Ультимы — это "БОСС-Компания" (не путать с «БОСС-Корпорацией»)
Любой скрипт — это программа, пусть даже маленькая. Но программы, пусть даже маленькие, тоже надо учиться писать и тестировать на отказы. В частности, чтобы не допускать таких ляпов.
Речь не о том, что нужно вкалывать от зари до зари. Наоборот, Досс имеет в виду осознание, что несмотря на усилия, ты делаешь гораздо меньше того, что мог бы, если… Если бы работа была умно организована. Если бы работа имела общественную значимость. И многое другое.
На похожую тему в 2018 году вышла ставшая популярной книжка "Bullshit jobs: a theory"
Вам не кажется, что многие синтаксические сласти (или даже, не побоимся этого слова, сладости) как минимум спорны и являют собой палку о двух концах, на одном из которых зачастую посажены грабли?
Простой пример, даже не из новых, а откуда-то из глубин C#4
var contact = new ActiveContact();
вроде всё ясно читается с листа. Но потом Вася переписал код на
var contact = schema.GetContacts("output");
какой теперь тип у contact? Правильно, не знаем, надо дополнительно лезть и смотреть. А если таких в теле метода десяток, то лезть и потом в голове удерживать.
Предвижу вечнозелёное: «Используйте тулзы!» Можно и «тулзы», но можно просто не полениться и набить «лишний» код, который, как показывает практика, с течением времени перестает быть лишним. Ведь программирование, хотелось бы надеяться, не просто набивание на клавиатуре, а в основном еще и некая мыслительная деятельность.
В РСФСР рождаемость стала ниже уровня воспроизводства (2,1 ребенка на 1 женщину) еще в 1960-е годы. В союзных республиках Азии та же картина, только с отставанием на 10-15 лет. Небольшой всплеск рождаемости был в 1984-86 гг. То что видно на графике в это время, следствие увеличения продолжительности жизни.
Обсуждаемый концепт реализован во множестве проектов «двухзвенок» с толстым клиентом, причем как концепт он обсуждался лет 20 назад.
Хмм… Представим себе типовое хранение хешей паролей в БД, проверкой которых занимается соответствующий сервис, напрямую соединяющийся с БД. Пусть длина цепочки передачи пароля до сервиса равна N. Теперь совместим сервис с СУБД. Длина цепочки остается N.
Не забываем учесть необходимую дополнительную авторизацию самого сервиса в СУБД, получаем две цепочки уязвимости вместо одной.
Ваш опыт сомнению не подлежит, но я бы не хотел переходить от обсуждений концептов к их реализациям.
Полностью с вами согласен, что масштабирование пары СУБД+СП имеет больше степеней свободы, чем СУБД со встроенным СП. Но как выше уже заметили, клиенту нужны не степени, а «чтобы работало по надежному сценарию, пусть даже одному».
Разумеется, процедурное расширение SQL может показаться менее подходящим языком реализации бизнес-логики, тут есть и плюсы (встроенный интегрированный SQL, высокая производительность связанного с СУБД кода, отсутствие перегонки данных между процессами), так и минусы (как правило слабая организация модульности, СУБД vendor lock, отсутствие ООП, более сложное тестирование). Это все понятно, остается выбрать баланс соответствия конкретному случаю.
Рассматривайте архитектуру, не как отсутствие сервера приложений (СП), а как реализацию сервера приложений средствами СУБД, тогда большинство вопросов отпадает. Вопрос про распределение нагрузки решается аналогичным образом, как и в случае выделенного СП.
Вопрос был «как сделать веб-клиент?», вроде бы я ответил. Как сделать веб-клиент без веб-сервера не совсем понимаю. Сюжет о разделении нагрузки — другой вопрос, опять-таки, не вижу, что там нужно дополнительно разделять по сравнению с исходной архитектурой. Бонусы появляются, да.
Технически это несложно: вместо тонкого rich-клиента пишется аналог на JS + web server. Вместо прямого использования SPID в протоколе поддерживается сессия и делается проброс контекста в слой бизнес логики (session id -> SPID), метод описан в книжке "СУБД для программиста"
P.S. к «минусованию» ваших комментариев никакого отношения не имею
Существовал (и вроде даже как-то дышит до сих пор) концептуальный аналог нашей Ультимы — это "БОСС-Компания" (не путать с «БОСС-Корпорацией»)
Редукционизм (вульгарный) снова в моде. «Все что не микросервисы, то монолит», «нарастим сеть до 80 млрд нейронов — будет мозг» и т.п.
На похожую тему в 2018 году вышла ставшая популярной книжка "Bullshit jobs: a theory"
Простой пример, даже не из новых, а откуда-то из глубин C#4
вроде всё ясно читается с листа. Но потом Вася переписал код на
какой теперь тип у contact? Правильно, не знаем, надо дополнительно лезть и смотреть. А если таких в теле метода десяток, то лезть и потом в голове удерживать.
Предвижу вечнозелёное: «Используйте тулзы!» Можно и «тулзы», но можно просто не полениться и набить «лишний» код, который, как показывает практика, с течением времени перестает быть лишним. Ведь программирование, хотелось бы надеяться, не просто набивание на клавиатуре, а в основном еще и некая мыслительная деятельность.
Схаматически, все что в одном слое/кольце может взаимодействовать друг с другом.