Существует ли веб-стек, оптимизированный для минимизации серверного кодирования?

Question

Для нескольких недавних проектов в нашей корпоративной интрасети я использовал очень простой стек nginx + redis + webdis + клиентский javascript для реализации некоторых простых инструментов анализа данных. Опыт был абсолютно замечательным, особенно по сравнению с моим предыдущим опытом с другими стеками (включая пользовательские C++, apache/mod_perl, ASP.Net MVC, .Net HttpListener, Ruby on Rails и немного Node.js). Учитывая наличие клиентских шаблонов и интерфейсных библиотек, таких как jquery-ui, кажется, что я мог бы с радостью реализовать гораздо более сложные веб-приложения, используя такой стежок без серверного кода (возможно, замену/добавление redis с помощью couchdb если это оправдано) ...

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

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

Answer 1

Я не могу комментировать рамки.

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

Рассмотрите один пример. Это довольно просто. Представьте себе службу HTTP, которая принимает SQL-запрос и возвращает коллекцию JSON, представляющую строки. Это просто написать. Вероятно, вы могли бы закрутить зарождающийся менее чем через час с нуля любой инструмент, который дает вам SQL-доступ к РСУБД.

Возможно, вернувшись в «Золотые дни разработки клиентского сервера», это именно то, что делали люди, только вместо некоторых данных, туннелированных по протоколу HTTP, люди использовали специфичный для БД драйвер и отправили SQL-текст обратно в базу данных напрямую ,

Проблема в том, что протоколы слишком открыты. Если вы выполнили упомянутую выше службу SQL, вы по существу превратите все свое приложение в вектор-инъекцию SQL.

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

CouchDB, например, не может быть обеспечен таким образом. Если у кого-то есть права на сервер, у них есть права на все данные. ВСЕ данные. Тот материал, который вы хотите видеть, и материал, который у вас нет.

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

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

Хранимые процедуры в основном были заменены слоями приложений и серверами приложений, причем БД все больше и больше отводится в «немое хранилище». Но понятия схожи.

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

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