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

[Nexus]

Программа, ограничивающая доступ, будет проверять пароль, беря пароль из базы данных.

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

[ГеннадийС]

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

[laimas]

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

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

Мы будем рассматривать этих двух пользователей чисто в плане прав, дабы исключить пакости, хотя у нас и так все по уму - все запросы формируются и инициализируются сервером. Все вроде бы Ок - пользователей я подключаю с привилегиями второго пользователя БД, а сам работаю со своими. Но ведь в этом случае база то мертвая будет. Что для меня означают мои посетители - учет, статистика и прочее, что позволяет реагировать на запросы/интересы, а значит процветать сайту. А что значит статистика, это значит слежение за пользователем - запись/обновление и т.п. Вот и получится, что для обслуживания одного запроса с привилегией SELECT придется открывать/закрывать различные соединения с БД, и если простой запрос на выборку зависит от иных данных, которые доступны только для соединения с расширенными привилегиями, то нехилая нагрузка лишняя возникает. А в случае запросов извне, да еще запрос "зуб даю, все честно", это еще и потенциальная очень опасная дыра.

[ГеннадийС]

Это относится к любому сайту. Тут нет особенностей.

[ГеннадийС]

Цитата:
laimas написал:
---------------------------------
Да и вообще. Пусть я имею двух пользователей БД, одного с правами как администратора, а второго только для выборки из БД. То, что тело запроса формируемое на клиенте разгружает сервер, это полнейший бред, о чем и полемизировать не стоит. А то, что в этом случае сервер лишен возможности фильтровать данные извне, что он обязан делать, есть предпосылка к большим неприятностям, это факт, и шифрование, еще не есть гарантия. Иное доказывайте школьникам, кому угодно, мне не надо.
-------------------------------------------------------------------
Я разочарован уровнем обсуждения. Зачем Вы мне описываете то, о чём я и так знаю? Я знаю, что злоумышленник имеет специальный браузер или самописное программное обеспечение, которое даёт возможность отправлять на сервер произвольные запросы.

И я уже писал, что ограничитель доступа не даст превысить уровень доступа.

Экономия в следующем: сервер обслуживает много клиентов и если сократить количество интерпретаторов, работающих на нём, то будет очень существенная экономия производительности.

[Белый шум]

Экономия в следующем: сервер обслуживает много клиентов и если сократить количество интерпретаторов, работающих на нём, то будет очень существенная экономия производительности.

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

Даже наоборот, вы даёте простую возможность положить сервер DoS атакой через формирование сложных и долгих запросов без индексов.

[ГеннадийС]

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

[Белый шум]

Я не верю, а знаю - если вы принимаете произвольные SQL-запросы от кого угодно, то можно составить такой запрос. Разумеется, это на реальных данных, а не тестовой БД с одной таблицей в 3 строки и двумя столбцами.

[ГеннадийС]

Засорили интересную тему бесполезной чушью.

То есть разработчики баз данных такие беспомощные, что не могут разбить сложный запрос на простые и выполнить их быстрее, чем выполнение таких же запросов, поступивших от php?

Белый шум, тут очевидное логическое противоречие. Зачем вы участвуете в этом обсуждении? Только отвлекаете от основной темы.

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

И тестовая база данных у меня из 10 таблиц, в которых сотни и тысячи тестовых данных.

[Белый шум]

Да я уже понял что зря вступил в разговор с теоретиком...