Перевірка введення даних завжди була для мене досить внутрішньою боротьбою.
На межі додавання реальної рамки безпеки та коду до нашого проекту перезапису застарілого додатка (який поки що значно зберігає застарілий код безпеки та перевірку даних), мені знову цікаво, скільки слід перевірити, де і т.д.
За свої 5 років, як професійний розробник Java, я створив і вдосконалив свої персональні правила щодо перевірки введення даних та заходів безпеки. Оскільки я люблю вдосконалювати свої методи, я хотів би почути кілька ідей від вас, хлопці. Загальні правила та процедури є чудовими, і специфічні для Java.
Узагальнено, це мої вказівки (викладені в трирівневому стилі веб-додатків) з короткими поясненнями:
Клієнт 1-го рівня (браузер): мінімальна перевірка, лише незмінні правила (обов'язкове поле електронної пошти, повинен вибрати один елемент тощо); використання додаткової перевірки на зразок "від 6 до 20 символів" рідше, оскільки це збільшує технічне обслуговування змін (може бути додано, коли бізнес-код стабільний);
Сторона сервера першого рівня (обробка веб-комунікацій, "контролери"): у мене немає правила для цього, але я вважаю, що тут слід обробляти лише помилки маніпулювання та збирання / розбору даних (поле дня народження не є дійсною датою); додавання подальшої перевірки сюди легко робить це дійсно нудним процесом;
2-й рівень (діловий шар): валідація твердих порід, не менше; формат вхідних даних, діапазони, значення, внутрішня перевірка стану, якщо метод не можна викликати в будь-який час, ролі / дозволи користувача та інше; використовувати якомога менше вхідних даних користувачів, за потреби витягнути їх знову з бази даних; якщо ми вважаємо отримані дані бази даних також вхідними, я би підтверджував їх лише у випадку, якщо деякі конкретні дані є досить ненадійними або пошкодженими в БД - сильне введення тексту робить більшу частину роботи тут, IMHO;
3-й рівень (рівень даних / DAL / DAO): ніколи не вірив, що тут потрібна велика перевірка, оскільки лише доступний бізнес-рівень повинен отримати доступ до даних (перевірити, можливо, у деяких випадках, наприклад, "param2 не повинен бути нульовим, якщо парам1 є істинним"); проте зауважте, що коли я маю на увазі "тут" я маю на увазі "код, який отримує доступ до бази даних" або "методи виконання SQL", сама база даних є абсолютно протилежною;
база даних (модель даних): повинна бути максимально продуманою, сильною та самозабезпеченою, щоб максимально уникати невірних та пошкоджених даних у БД, з хорошими первинними ключами, зовнішніми ключами, обмеженнями, типом даних / довжиною / розміром / точність тощо - я залишаю тригери поза цим, оскільки вони мають своє приватне обговорення.
Я знаю, що раннє підтвердження даних є приємним та ефективним, але повторна перевірка даних - це нудний процес, і я визнаю, що перевірка даних сама по собі досить дратує. Ось чому стільки кодерів пропускають це чи роблять це на півдорозі. Крім того, кожна дублювана перевірка є можливою помилкою, якщо вони не синхронізуються постійно. Це основні причини, з яких я сьогодні вважаю за краще віддати більшість перевірок до рівня бізнесу за рахунок часу, пропускної здатності та центрального процесора, винятки обробляються у кожному конкретному випадку.
Отже, що ви думаєте з цього приводу? Протилежні думки? Чи є у вас інші процедури? Посилання на таку тему? Будь-який внесок є дійсним.
Примітка: якщо ви думаєте, як робити Java способи, наш додаток - Весна, заснована на Spring MVC та MyBatis (продуктивність та погана модель бази даних виключають рішення ORM); Я планую додати Spring Security як наш постачальник безпеки плюс JSR 303 (Hibernate Validator?)
Спасибі!
Редагувати: додаткові роз'яснення на 3-му шарі.