Чи є якась причина не переходити безпосередньо від клієнтського Javascript до бази даних?

Можливий дублікат:
написання веб-додатків "менше сервера"

Отже, скажімо, я збираюся створити клон Stack Exchange і вирішую використовувати щось на зразок CouchDB в якості свого бекенда. Якщо я використовую їх вбудовану аутентифікацію та авторизацію на рівні бази даних, чи є якась причина не дозволити клієнтові Javascript писати безпосередньо на загальнодоступному сервері CouchDB? Оскільки це в основному додаток CRUD, а бізнес-логіка складається з "Тільки автор може редагувати свою публікацію", я не бачу великої необхідності мати шар між матеріалами на стороні клієнта та базою даних. Я просто використовував би валідацію на стороні CouchDB, щоб переконатися, що хтось не вводить дані про сміття, і переконатися, що дозволи встановлені належним чином, щоб користувачі могли читати лише свої власні дані користувача. Відображення здійснюватиметься на стороні клієнта чимось на зразок AngularJS. По суті, ви могли просто мати CouchDB-сервер і купу "статичних" сторінок, і ви готові йти. Вам не знадобиться будь-яка обробка на стороні сервера, лише те, що може обслуговувати HTML-сторінки.

Відкриття моєї бази даних у світі здається неправильним, але в цьому сценарії я не можу придумати, чому дозволу встановлено належним чином. Це суперечить моєму інстинкту як веб-розробника, але я не можу думати про вагомі причини. Отже, чому це погана ідея?

EDIT: Схоже, тут є подібна дискусія: Написання веб-додатків "менше сервера"

EDIT: Поки що дивовижна дискусія, і я ціную відгуки всіх! Я відчуваю, що мені слід додати кілька загальних припущень, а не викликувати CouchDB та AngularJS спеціально. Тож припустимо, що:

• База даних може автентифікувати користувачів безпосередньо зі свого прихованого сховища
• Весь зв’язок із базою даних відбуватиметься через SSL
• Перевірка даних може (але може бути, не слід) обробляти базу даних
• Єдиний дозвіл, який нас цікавить, окрім функцій адміністратора, - це те, хто має право редагувати власну публікацію
• Ми прекрасно вписуємось у те, що кожен може прочитати всі дані (ОКРИМИ записи користувачів, які можуть містити хеші паролів)
• Адміністративні функції обмежуватимуться авторизацією бази даних
• Ніхто не може додати себе до ролі адміністратора
• База даних порівняно легко масштабувати
• Справжньої логіки бізнесу майже немає; це базовий додаток CRUD

Діяння, як ви пропонуєте, створює тісну (ер) зв'язок між мовою клієнтської сторони та вашою базою даних.

Це може бути гаразд - менше писати та підтримувати код, і теоретично налагодження могло / повинно пройти трохи швидше.

З іншого боку, це ускладнює інші аспекти. Якщо / коли вам потрібно буде змінити будь-яку з цих технологій, вам буде складніше через тісний зв'язок між ними.

Захистити себе від нападів буде (зовсім) трохи складніше. Ви припускаєте, що клієнт завжди буде подавати в базу даних добре відформатовані запити. Це передбачає, що ніхто ніколи не буде зламати код клієнтської сторони, щоб вставити шкідливі заяви. Іншими словами, вони "запозичать" ваші механізми аутентифікації та замінять звичайний код клієнта на їхній.

Я б не рекомендував це, і багато хто з лютістю сказав би вам цього не робити. Але це можна зробити.

Це, мабуть, не чудова ідея. І перша і найсильніша причина, яку я можу навести, - це те, що сервер баз даних не розроблений як публічний веб-сервер. Навпаки, звичайна мудрість говорить, що ви повинні ховати свою базу даних за брандмауером.

Якщо вам потрібні підтверджуючі докази, виникає безліч проблем - не все непереборне, але багато про що подумати. Окремого порядку тут немає:

• Він не може виконати санітацію запитів, оскільки ви надсилаєте йому запити безпосередньо.
• Дозволи на базу даних, як правило, працюють інакше, ніж дозволи на веб-сервер та програми. Веб-сервери та рамки додатків запускають вас ні з чого, і вам потрібно чітко створити та викрити окремі ресурси, кінцеві точки та дії. З іншого боку, бази даних просять надати ролі на високому рівні.
• Це, мабуть, недостатньо оптимізовано для підтримки завантаженості веб-сервера; Ви не можете скористатися об'єднанням з'єднань
• Більш популярні веб-сервери були розбиті на безліч . І вони отримали багато патчів безпеки. Ваша СУБД в основному була розроблена для того, щоб ховатися за брандмауером, тому, ймовірно, її не перевірили навіть частка відсотків потенційних загроз, з якими вона зіткнеться в загальнодоступній мережі.
• Ви повинні використовувати мову запитів бази даних для захисту приватних даних. Залежно від вашої СУБД, це може бути складним завданням.
• Ви повинні використовувати мову запитів бази даних для фільтрації великих наборів даних - те, що ви могли б прагнути зробити у будь-якому випадку; але щось, що може стати обтяжливим для складніших правил бізнесу.
• Обмежена підтримка сторонніх бібліотек або їх відсутність.
• Дуже обмежена (потенційно нульова) підтримка спільноти для багатьох проблем, з якими ви зіткнетесь.

... І я впевнений, що є й інші проблеми. І я впевнений, що для більшості є рішення - якщо не всі ці проблеми. Але, є список для початку!

Найкраща причина, яку я можу собі уявити, - це те, що цей метод не підтримується і не рекомендується жодною стороною.

Постачальники веб-переглядачів, стандарти EcmaScript, розробники систем баз даних, компанії з мережевого обладнання, архітектори хостингу / інфраструктури та фахівці з питань безпеки не активно підтримують (або, можливо, навіть враховують) запропонований вами варіант використання. Це проблема, оскільки ваш запропонований метод вимагає, щоб усі ці сутності - і більше - працювали належним чином для вашої програми, хоча жодна із залучених систем не була розроблена для цього.

Я не кажу, що це неможливо. Я просто кажу, що це менш схоже на "переосмислення колеса" і більше, як переосмислення взаємодії клієнт-сервер на основі браузера.

У кращому випадку ви будете робити багато робіт, щоб навіть системи змусили працювати на самому базовому можливому рівні. Сучасні популярні бази даних не є RESTful або створені для роботи над HTTP, тому ви будувати власні драйвери клієнтів на базі WebSocket (я припускаю).

Навіть якщо ви змусите все технічно працювати, ви відмовитеся від багатьох найпотужніших особливостей сучасних архітектур. У вас не буде захисту в глибині - кожен може легко підключитися безпосередньо до первинної цілі більшості спроб злому веб-сайту. Але запропонований вами сценарій є набагато, набагато гіршим за це.

Запропонована модель не є лише експонуванням сервера - це відкриття дійсних рядків з'єднання. Зловмисники не можуть просто пінг-сервер - вони можуть активно входити в систему і подавати команди. Навіть якщо ви можете обмежити доступ до даних, я не знаю достатнього інструментарію в системах СУБД для захисту від сценаріїв відмови у сервісі та їхніх помилок. Під час роботи в розширених версіях SQL, як-от TSQL, часто створювати бомби, які працюють безперервно, є неправдиво (декілька необмежених приєднань для отримання декартового продукту, і ви матимете SELECT, який працюватиме назавжди, виконуючи важку роботу) . Я думаю, вам потрібно буде відключити більшість функцій SQL, навіть усунувши основні SELECT запити з JOIN і, можливо, дозволяти лише викликати збережені процедури? Я навіть не знаю, чи можете ви це зробити, мене ніколи не просили спробувати. Це не так

Масштабованість баз даних також є однією з найскладніших проблем роботи на великих масштабах, а масштабування декількох серверів HTTP - особливо зі статичними або кешованими сторінками - є однією з найпростіших частин. Ваша пропозиція змушує базу даних робити більше роботи, відповідаючи за 100% активності на сервері. Це вбивча вада сама по собі. Що ви отримуєте від переміщення роботи на клієнта, який ви втрачаєте, переміщуючи більше роботи на базу даних.

Нарешті, я хотів би лише зазначити, що серце запропонованого вами не є новим, а насправді сягає десятиліттями. Ця модель називається моделлю "жирна база даних", яка в основному перемістила більшість логіків на сервері в базу даних так само, як ви пропонуєте. Існує багато причин того, що модель відійшла в сторону масового Інтернету, і, мабуть, було б корисно зазирнути більше в цю історію. Зауважте також, що навіть тоді було мало уваги щодо того, щоб повністю ненадійні користувачі могли увійти в систему та запустити команди, оскільки доступ все ще контролюватиметься для вибору внутрішніх (відомих) користувачів, які не повинні були постійно атакувати систему.

Справа в тому, що вам все одно потрібен сервер HTTP для обслуговування файлів, оскільки системи баз даних просто не роблять цього. У той же час все, що ви пропонуєте, можна отримати, використовуючи тонку модель сервера (наприклад, з Nodejs), щоб відкрити інтерфейс RESTful до вашої бази даних. Це популярно чомусь - воно працює, зберігає базу даних прихованою за шарами захисту, є надзвичайно масштабованою, але все ж дозволяє будувати базу даних настільки товстою або тонкою, як вам потрібно.

Оскільки це в основному додаток CRUD, а бізнес-логіка складається з "Тільки автор може редагувати свою публікацію", я не бачу великої необхідності мати шар між матеріалами на стороні клієнта та базою даних. Я просто використовував би валідацію на стороні CouchDB, щоб переконатися, що хтось не вводить дані про сміття, і переконатися, що дозволи встановлені належним чином, щоб користувачі могли читати лише свої власні дані користувача.

Отже, розміщення вашої авторизації (проблеми безпеки) та перевірки логіки подалі від бази даних забезпечує розділення проблем у вашій програмній системі. Таким чином, ви можете протестувати, підтримувати, масштабувати та використовувати свої блоки логічного коду з меншими ризиками гальмування функціональності в системі.

Надання можливості для клієнтського вводу безпосередньо спілкуватися з Database має дуже великий потенціал для виведення даних .

Це також означає, що уникнення / зняття щільного з’єднання зробить вашу програмну систему більш стійкою та твердою.

Дозвіл користувача безпосередньо взаємодіяти з базою даних здається мені справді небезпечним.

Чи справді механізм аутентифікації CouchDB настільки складний, що ви можете ізолювати доступ користувача для читання та запису лише до тих даних, які він повинен читати і записувати (ми говоримо про документ, можливо, навіть за один документ у полі пільги тут)? А як щодо "комунальних" даних, якими ділиться кілька користувачів? Хіба це взагалі не існує у вашій програмі?

Ви дійсно хочете, щоб користувач міг змінювати свої дані будь-яким способом? Що, наприклад, про ін'єкції XSS? Чи не було б краще мати серверний шар для фільтрації тих, хто потрапляє до бази даних?

У вас є ряд причин, але ось ще одна: впевненість у майбутньому. Рано чи пізно, у міру розвитку вашої програми, вам буде пред'явлено певну вимогу, яку неможливо досягти легко або надійно в JS на стороні клієнта або як збережена процедура у вашій базі даних.

Наприклад, вам кажуть, що для всіх нових реєстрацій для підтвердження дійсності повинна бути перевірка CAPTCHA. Це було б справді досить просто, майже з будь-якими сучасними рамками веб-додатків. Просто ляпніть reCAPTCHA у реєстраційній формі, передайте маркер відповіді reCAPTCHA назад у бекенд і додайте пару рядків коду у свій бекенд, щоб перевірити дійсність маркера за допомогою API Google (а ще краще, використовуйте бібліотеку, яку хтось інший написав для цього для вас).

Якщо ви використовуєте дворівневу систему і покладаєтесь на базу даних для всієї логіки на вашому сервері, як ви збираєтеся перевірити маркер? Так, я вважаю, що теоретично можливо, в залежності від СУБД, записати збережену процедуру, яка якось викликає оболонку і викликає curl з відповідними аргументами. Це також майже напевно жахлива ідея: фільтрування вхідних даних та захист від вразливості безпеки були б жахливими; у вас виникне безлад, пов'язаний з обробкою помилок та таймаутами; і вам доведеться самостійно проаналізувати відповідь. Не кажучи вже про те, що СУБД не призначена для цього, тому немає підстав думати про продуктивність, стабільність, безпеку потоків тощо ... не буде проблем. Дивіться, наприклад, цю тему , в якій обговорюються деякі з цих питань для Postgres.

І це лише питання щодо додавання однієї простої CAPTCHA до форми. Що ви будете робити, якщо хочете додати підтвердження SMS або фонову роботу, яка надсилає електронні повідомлення неактивним користувачам, щоб нагадати їм про ваш додаток або додати функцію завантаження файлу, щоб люди могли встановити зображення профілю? Можливо, ви вирішили, що у вашій програмі колись повинні пройти автоматизовані тести? Або ви хочете відслідковувати зміни в своїх процедурах у системі контролю версій? Існує чимало бібліотек та інструментів для більшості корисної мови для обробки більшості цих завдань для вас, але мало хто до жодної буде доступний для ваших СУБД, тому що це не призначено для цього.

Зрештою, вам захочеться зробити щось, чого ви не можете розумно зробити безпосередньо у вашій СУБД, і тоді ви застрягнете. Оскільки ви створили всю свою програму у вашій СУБД, вам не буде альтернативи, як отримати веб-сервер і почати перебудову фрагментів іншою мовою, просто для додавання простої функції.

І це було б справжньою ганьбою, оскільки ми вже маємо назву місця, де ви розмістили логіку програми, і це називається "вихідний код вашої програми", а не "процедури, що зберігаються в базі даних".

Якщо ваші перевірки безпеки та бізнес-логіка містяться у вашому клієнтовому javascript, їх може перекрити шкідливий користувач. Як альтернатива, ви можете використовувати технологію на базі сервера на базі JavaScript (наприклад, Node.JS ) для обробки валідації, авторизації тощо.

Будь-яке обмеження бізнесу, яке ви хочете забезпечити, повинно бути підтверджене на стороні сервера. Навіть якщо ви контролюєте доступ користувачів, хтось може надсилати недійсні дані.

Слідуючи прикладу клонування stackoverflow:

• Як би ви заблокували редагування "закритих" питань на сайті?
• Як би ви запобігли людям видаляти коментарі?
• Як би ви запобігли людям підробляти дати коментарів?
• Як би ви завадили людям опублікувати 50 разів одну і ту ж посаду?
• Напевно, є набагато більше прикладів, якщо ви копаєте трохи більше.

Будь-хто може маніпулювати кодом клієнтської сторони та повністю порушувати цілісність даних (навіть якщо це обмежено певними об'єктами, наприклад, їх власними повідомленнями).

Відредагуйте сторінку в firebug і в якийсь момент поставте рядок, подібний до цього:

ExecDbCommand("DROP TABLE Users")

Виконати його.

Редагувати:

Питання було насправді про CounchDB, тому тут не бігати sql. І все ж ідея та сама. Я б припустив, що будь-яке нетривіальне додаток залежить від даних щодо дотримання деяких правил узгодженості, які перевіряються / виконуються кодом програми. Зловмисний користувач може змінити код клієнта, щоб зберегти дані у формі, яка порушує ваші правила бізнесу та може спричинити хаос у вашій програмі.

Якщо ваш сайт вважає, що всі можливі стани даних є дійсними з точки зору бізнесу, то будь-якими способами слід пройти цей маршрут, але якщо це не так (ймовірно), ви хочете мати гарантію, що будь-які дані, що зберігаються, генеруються вашими код та відповідно до ваших правил .

Я знаю, старе запитання, але я хотів передзвонити, бо мій досвід є зовсім іншим, ніж інші відповіді.

Я багато років писав додатки для спільного використання в реальному часі. Загальний підхід для цих додатків полягає в тому, щоб копіювати дані локально і якнайшвидше синхронізувати зміни з однолітками. Усі операції над даними локальні, тому всі сховища даних, доступ до даних, бізнес-логіка та інтерфейс користувача є шарами локальними. Рух "офлайн перший" ( http://offlinefirst.org/ ) прийняв такий підхід для створення офлайн-веб-додатків і може мати деякі відповідні ресурси. Такі випадки використання не тільки вимагають відкриття шару доступу до даних клієнтам, але і зберігання даних! Я знаю, я знаю. Здається, божевільно, правда?

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

Перша помилкова думка полягає в тому, що оголення бази даних означає оголення всіх даних. Візьмемо, наприклад, CouchDB; бази даних у CouchDB є легкими, тому вам би й думки не було про створення сотень тисяч окремих баз даних на сервері. Користувачі можуть отримувати доступ лише до баз даних, яким їм надано дозвіл на доступ як читач або записувач (не кажучи вже про функції перевірки, а не про CouchDB), тому вони можуть отримати доступ лише до підмножини даних.

Друга помилкова думка полягає в тому, що користувач, скачуючи дані, є проблемою! Якщо користувачам дається репліка бази даних, вони можуть лайно використовувати все, що їм заманеться, не зачіпаючи інших користувачів. Але слід підтвердити їх зміни, перш ніж реплікувати їх дані назад у "центральний" магазин. Подумайте про Git - користувачі можуть робити все, що завгодно, у гілках, виделках та локальних сховищах, не впливаючи на головну гілку. Злиття спини з майстром передбачає багато церемоній і не робиться наосліп.

Зараз я будую систему, використовуючи CouchDB, де користувачі повинні співпрацювати над даними, щоб створити набір даних, який потім "публікується" через робочий процес QA / QC. Співпраця здійснюється за репліками даних (ми називаємо це стадіонною або робочою базою даних), і після завершення відповідальна особа виконує QA / QC над даними і лише після цього вона реплікується назад у основний сховище.

Від цього випливає багато переваг, яких важко досягти в інших системах - наприклад, управління версіями, реплікація та співпраця (нехай працює в автономному режимі!) Для традиційних трирівневих програм CRUD дуже важко.

Моя порада - якщо ваша заявка "традиційна", тоді робіть це традиційним способом. Якщо будь-яке з речей, про яке я згадував вище (хоча є ще багато…), стосується вас, тоді розгляньте альтернативні архітектури та будьте готові думати збоку.

Я думаю, що зважаючи на всі ваші припущення, можливо, безпосередньо перейти від клієнта до бази даних. Однак розумно перевірити, чи ваші припущення справедливі, і, ймовірно, так і залишаться в майбутньому.

Я б хвилювався, що в майбутньому може бути не нормально, щоб усі читали всі дані, а особливо, що це може розвинути більше ділової логіки в майбутньому. І те й інше є більш імовірним, якщо проект буде успішним.

Поки ви залишаєте собі спосіб вирішити ці проблеми в майбутньому, коли і якщо вам потрібно буде з ними впоратися, я думаю, що ваш дизайн буде працювати. Я думаю, вам потрібно буде бути особливо обережними, щоб розділити проблеми в коді JavaScript, і деякі з них можуть бути переписані пізніше на сервері.

Але я точно міг би побачити, де це може бути ризиком, можливо, зробити це пізніше порівняно з користю меншої кількості рухомих частин сьогодні.

Перш за все, дякую за запитання ВІД КОРОБУ .... :)

Але те, що я б сказав, це; Завжди намагайтеся підтримувати поділ між трьома шарами. які представляють презентацію / бізнес та базу даних або DAO, оскільки це буде найкращою практикою в тих видах вимог та налаштуваннях, де щодня буде багато змін.

У простих світах ваш презентаційний шар не повинен знати про рівень бази даних, тобто формат полів деяких типів дати може відрізнятися від рівня презентації та рівня бази даних, щоб користувач міг мати свободу вибору відповідного формату дати відповідно до його потреб.

І Business Logic повинна діяти як зв’язок між шаром презентації та шаром бази даних / Dao, як лиття полів, деякі перевірки бізнесу тощо, слід обробляти на Business Layer, а не в розділі Javascript відповідно до вашого питання.

Ця сегрегація забезпечить вам велику легкість та зручність під час складних сценаріїв, функціональності та навіть складних перевірок. Найкраща перевага полягає в тому, що ви можете мати різні технології для впровадження цих шарів і їх можна змінювати відповідно до потреб бізнесу чи сфери діяльності.

Дякую

Якщо ви хочете створити SQL в JavaScript і відправити його в базу даних, яка підтверджує права і т. Д., То з причини безпеки це було б катастрофою. Просто тому, що, будуючи API та будуючи запити самостійно, вам доведеться аналізувати з точки зору безпеки лише обмежену кількість запитів. Якщо запити побудовані за межами вашої системи, у вас є потенційно необмежена кількість хитрощів, які хтось може зробити.

Але це не так, оскільки ви використовуєте базу даних ключових значень (настільки справедливо, наскільки я розумію, CouchDB взагалі потрапляє в цю категорію). Сам інтерфейс бази даних є свого роду середнім рівнем, і він перевіряється з міркувань безпеки командою Apache. Через відносно простий JavaScript API це простіше проаналізувати на потенційні недоліки, ніж такі складні інтерфейси, які мають програми JSF.

Це може бути безпечним рішенням, якщо ви робите складні тести безпеки. Це може бути ще простіше, як при використанні фреймворків, таких як JSF, які часто використовують важко читабельний API позаду. Безпека від невідомості не вважається рішенням.

Що стосується вашого запитання, то це не буде прямим доступом до бази даних. Прямий доступ був би побудовою SQL-запитів у JavaScript (на жаль, я бачив такі рішення). У вашому випадку CouchDB сам забезпечує шар ізоляції. Звичайно, ви можете зафіксувати його у своєму API, щоб затвердіти, але поки ви зможете легко перевірити, що може зробити конкретний користувач, і якщо обмеження безпеки працюють для вас, у вас буде безпечне і надійне рішення без додаткових шарів.

Я бачу дві проблеми:

1. Щільне з'єднання: змінити параметр БД? Ну, тепер вам також потрібно змінити весь код на стороні клієнта. Довірся мені. Нам не потрібно більше проблем на стороні клієнта.

2. Випуск безпеки TMI: занадто багато розкриває спосіб роботи. Auth все ще може стати перешкодою, але знайти подвиг - це пекло набагато простіше, коли ви точно знаєте, що відбувається на стороні сервера.

Дуже-дуже тонкий середній рівень може бути кращим способом.

Ваш клієнт не може використовувати ваше веб-додаток, якщо JavaScript відключений (або не підтримується в браузері його пристрою), якщо javascript є єдиним рівнем доступу до бази даних.