Долой backend! Все делаем на javascript в frontend.
 

Все мы прекрасно знаем, что есть frontend и backend, программирование на стороне клиента и сервера. Чаще всего для создания вебсайта требуются специалисты по mysql, php, javascript, html, css. Многовато будет. Вот хотя бы избавиться от пары языков например php и sql. Без sql не обойдешься, но по крайней мере можно ограничиться самым минимальным набором команд, как делает facebook, у них запросы самые простые ключ-значение.
Далеко не каждыЙ программист знает как работает жесткий диск и что влияет на время выполнения запроса, сложный sql запрос может оказаться очень медленным.
От php уже избавился node.js, но он работает только со своим сервером и специалистов не так много и они дорогие. Когда вся функциональность находится в одном месте это значительно упрощает сопровождение программы.
Хотелось бы иметь такую систему:
1 программирование происходит на стороне клиента, возможно с использованием frameworks
Angular (2,1), React, Vue.js, Ember, Meteor.
2 используется обычный хостинг или сервер. Фактически программист может даже не знать о серверной стороне, для него процессор оперативная память и диск сервера это всего лишь расширение браузера.
Сделать это совсем не трудно с помощью ajax. Но защититьjavascript код принципиально не возможно так что система получается неприемлимой с точки зрения безопасности. Можно использовать препроцессор, писать все на javascript, а потом генерировать код на php (или другом языке). Препроцессор может делать много других полезных вещей:
1 Проверять качество javascript, html, css кода.
2 Проверять комментированность кода и вообще соблюдение принятого корпоративного стандарта программирования
3 Проверять защищенность от sql инекций и cross site scripting.
4 Генеририровать автоматическую настройку на размер экрана.
5 Генерирвать простейшую мобильную версию.
6 Оптимизировать скорость загрузки страницы. Например удалять из js библиотек (jquery, angular и тд) не используемые функции, выполнять загрузку по мере просмотра страницы. Очень эффективно также сначала загружать относительно небольщие изображения худшего качества, например, меньшего разрешения или в формате gif .
Выглядит система примерно:
так программист на js имет набор операторов обращения к памяти сервера: оперативной ,
файлам на диске, базам данных, журналируемым хранилищам (redis, memcached). Можно вообще каждой переменной, массиву и объекту js поставить в соответствие переменную, массив или объект на серверной стороне с таким же именем. Те чтобы серверная часть была как можно менее заметна.
Кое что в этом направлении уже сделано:
Javascript parser, compiler and interpreter written in PHP
http://sstur.github.io/js2php/demo/
https://github.com/jakubkulhan/js2php

Хотелось бы знать Ваше мнение по всему выщемзложенному.
Предлагаю основать open source проект и разработать такую систему.

Хорошая шутеичка братан =)

отвечай по существу братан.

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

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

А зачем пароль? Атакующий тот же пользователь, а подключение к базе от имени владельца. Но в случае формирования запросов сервером пользователю даже структура таблиц неизвестна, а в случае формирования запросов клиентом, вы не то что структуру вываливаете на общее обозрение, но еще и связи.

Без пароля не выйдет получить данные. А что даст знание структуры?

Я не очень хорошо знаком с хакерскими атаками на базы данных.

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

Страшна SQL инъекция, а для ее предотвращения входные данные которые являются параметрами запроса обязательно подвергают фильтрации, их экранируют и т.п., что исключить подстановку в запрос запроса от атакующего.

В случае если клиент формирует запросы, о какой фильтрации может идти речь? А как быть с закрытыми для пользователей разделами, доступами и правами, запрос к этим данным тоже клиенту формировать?

В сети полно описания об инъекциях баз данных, читайте например на хакер.ру.

Пароль владельца сайта неизвестен пользователю. У него свой пароль. Ограничитель доступа получает запрос от javascript с паролем пользователя и его логином. Дальше он получает из базы данных сведения о правах данного пользователя и ограничивает выдачу. Таким образом, хакер не сможет получить пароль владельца сайта. Вообще то хакер не сможет получить и пароль пользователя, если он не является пользователем сам.

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

Вы путает мух с котлетами.

У нас с Вами взаимонедопонимание. Я не предлагал отказываться от ограничения доступа. Эта функция обязательна. Многим нужен многоуровневый доступ пользователей к базе данных. Разные группы пользователей могут выполнять разные запросы и получать доступ к разным данным. Эта функция обязательна. Правами root пользуется только ограничитель доступа.

Запросами должен управлять сервер, есть при этом права, нет ли таковых, это не важно. Клиент должен оперировать только данными, а не запросами. Хотите иметь дыру - пожалуйста, пишите SQL запросы непосредственно на клиенте и отдавайте их серверу на исполнение.

Вот об этом я и спросил в первом своём посте в эту тему. Чем опасно показывать структуру базы данных, хотя бы частично?

Код многих известных CMS (не берем Битрикс, он упакован) свободно доступен в сети. Естественно, что открытый код анализируется на уязвимости (это справедливо и к приложениям с открытым кодом) для дальнейшей их эксплуатации. Точно не помню, но вроде бы Джумлу взламывали "угадывая" префикс имен полей таблиц.

Вы владелец сайта, хост вам определил доступ к панели управления им - логин, пароль. Вы определяете пользователя FTP и БД, указывая логин и пароль. Именно по этому логину и паролю будет производится подключение к БД. Логин и пароль пользователя Федя, под которым он зарегистрировался SQL побоку. SQL также наплевать какие права вы определили для Феди, может к примеру только читать посты, или же удалять чужие.

Я атакующий, обычный пользователь, мне надо попотеть, чтобы в грамотно организованной безопасности пробить брешь. А тут такой подарок - мне разрешено на клиенте писать "SELECT ... FROM ...", не жизнь, а малина. Вы что думаете, что не определив мне права делать запрос к таблице Х обезопасили себя?

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

Грамотно, это даже вывод SQL ошибок не делают, только в режиме отладки и кому эта отладка доступна. Если формы оперируют именами полей таблиц, то это только часть имени, другая часть известна только серверу. Любая информация по структурам таблиц, это пища для анализа атакуемому, и чем больше такой пищи, тем более обширна для него стратегия. А если еще код дырявый, то это вообще подарок.

Безопасность приложения, это долгий разговор, "спрятал от глаз структуру и все ОК" не есть защита. Ищите в сети и читайте, это очень обширный материал, ибо веб приложение, это клиент+сервер, и вопросы безопасности актуальны для обеих сторон.

Ладно. Остаюсь при своём мнении. Если в базе данных есть уязвимость, позволяющая хакеру получить ответ на select, то и на show он сможет получить ответ. Если доступ ограничен сервером, то знание структуры базы данных ничего не даст.

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

Да на здоровье. :)

Вы просто не понимаете, что такое БД, отсюда у вас и "детские болезни". ;)

Надеюсь меня не примут за троля.

Это правда, я не эксперт по базам данных. Но мне хватает знаний развернуть сервер базы данных, создать подходящую под задачу структуру базы данных, заполнить её данными. Хватает знаний написать интерфейс на javascript, с созданием, изменением, удалением и поиском.

Но имеются и пробелы в знаниях. Зашёл на форум и увидел эту тему. Она мне показалась интересной, поэтому я хотел обсудить её по существу.

Безопасность, это святая обязанность сервера. Что значит писать запросы на клиенте и с чего вдруг это разгрузит его? Это наоборот создает для него такие проблемы, что врагу не пожелаешь. Вы слишком поверхностно все это себе представляете, видимо отсюда такие неверные представления.

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

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

Мне уже приходится повторять. Я с самого начала упомянул, что кроме базы данных на сервере должен быть ограничитель доступа. Даже он может не иметь прав (привелегий) root. Ограничитель при поступлении запроса от клиентского javascript запрашивает из базы данных пароль пользователя и проверяет его. Если пароль совпадает, то ограничитель запрашивает права пользователя и ограничивает запрос в соответствие с правами. Дальше запрос выполняется, ответ базы данных отправляется клиенту.

laimas, SQL на привилегии Феди - пофиг, СУБД же не пофиг. Она не позволит Феде совершать действия, что ему не позволены.

Если sql будет выполняться от read-only пользователя, то что злоумышленник сможет сделать кроме сношения сервера БД?

А что такое "ограничитель доступа"? Нет привилегий root, это пользователь, а привилегия GRANT.

Причем тут вообще пользователи, если клиент формирует запрос?! Неужели не понятно, что именно это дыра?

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

Клиент, это терминал с монитором, а CPU, это как раз сервер. Не надо подменять понятие "производительность" глупостями. Пишут всякие валидаторы на клиенте, полагая что на этом все и заканчивается, и шлют мусор этот серверу, не делая на нем даже минимальной проверки.

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

Делайте, что хотите. Трудно приводить доводу тому, кто не понимает. )

Nexus,
и вы туда же. Не надо мне тюльки вравлять. )

laimas, мне действительно интересен ответ на вопрос, может я чего не знаю.

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

Почему стоит разгрузить сервер? У пользователей (клиентов) большие мощности ничего не делают. Вся нагрузка по формированию страниц на сервере. На сервере работает база данных, php, фреймворк какой-нибудь. Это влечёт не только необходимость в более производительных серверах, но и в расходах на программистов.

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

Функцию трансляции запросов от клиента в базу данных (с ограничением доступа) можно возложить на cgi программу или на модуль Apache или ещё на что.

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

Вот что предлагается - писать на клиенте "SELECT ...". Это для кого? Для продвинутых пользователей? Глупо. Для администратора? Зачем?

А если "для разгрузить" и администратор, то тогда уже и INSERT. И пусть в неких рамках то что я напишу будет не опасно, но где гарантия того, что это не будет использовано с высокими привилегиями например в других запросах?

О чем речь, о песочнице? Нахрена она нужна? Если сервер принимает на веру и тупо проглатывая все что ему дает сервер, это не все что угодно, но не приложение, какое оно должно быть.

Слова о разгрузке сервера, а тем более, что это безопасно, это просто словоблудие.

Вот и весь ответ.

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

laimas, меня разгрузка и не волновала от слова "совсем" )
Грабли выстрелить могут, но если опустить это, закрыть глаза на то, что сервер бд могут положить уймой тяжелых запросов и слить всю бд, то что злоумышленник может еще сделать?
Ничего же, верно?
(при условии, что у пользователя бд привилегии только на чтение).

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

Разгружайте сервер тем, чем ему действительно не стоит заниматься, но это к БД не относится.

Для какого пользователя? Федей, Ваней, Наташ ....? Читайте в чем суть вопроса.

laimas, запрос без пароля и логина не будет выполнен. Единственная "уязвимость" здесь знание пользователем структуры базы данных (если он может проанализировать код, то есть пользователем стал злоумышленник). Что он сможет сделать? Писать произвольные запросы. Но он получит выдачу только на те запросы, которые соответствуют его уровню доступа.

Простите, но Вы много эмоциональных восклицаний используете, но ни разу не сообщили по существу.

У единственного пользователя БД, других нет и у этого пользователя права только на чтение записей.

Опять двадцать пять.

Запустить цикл во вкладке, который будет отправлять на ваш сервер 500 запросов в секунду на выгрузку всех записей из всех доступных ему таблиц.
Или это не стоит внимания?

Даже и не знаю как комментировать. :)

laimas, в заданных условиях как-либо навредить (кроме опущенных случаев) злоумышленник не сможет, верно? )

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

Если иметь привилегию только на SELECT, то нет. Но в чем смысл этого? Строковое значение (тело запроса) прописанное клиентом, а не сервером, никак не снимает нагрузку на сервер, запрос все равно сервер исполнять будет. Уже полнейшая глупость довода, что это разгружает сервер. А вот нагадить серверу можно, он же только исполнять будет, не проверяя.

laimas, меня интересовало можно или нет, ни больше, ни меньше.
Если это возможно, то я обязан это знать, поэтому вас и мучал, простите :)

Тема называется "Долой backend!" В первых сообщениях предлагалось не использовать серверные языки программирования и обойтись минимумом программного обеспечения на сервере. Базы данных нужны всё равно. Я и хотел обсудить такой способ построения сайта.

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

Да банально просто напишу запрос, который будет ложить SQL сервер, ведь мне же разрешено (!) писать запросы. А писать грамотные запросы, это нужно знать не только структуру таблицы, но и типы полей, что будет подспорьем в плане нагадить. А ведь запросы можно то делать вложенными, ну почему бы не завалить такой доверчивый сервер? ;)

Это мне известно, об этом упоминал.