Резюме зустрічі 20.10.15

🔉 Аудіо

📺 Відео - таймінг

Демонстрація фіч

Реєстрація на подію

🕒 [0:00 - 2:19]

• /events/{event_id}/register;
• у відповіть повертається url події, що далі робити з цим url - вирішує клієнт;
• до таблиці visit_log додається інформація про реєстрацію на подію;

Логін на сайт

🕒 [2:19 - 2:50]

• /login;
• при логіні з невірними даними (логін, пароль) - поверається відповідь з кодом 401;

Реєстрація користувача

🕒 [2:50 - 4:35], 6:50 - 10:00]

• /users/register;
• треба вводити логін (email) і пароль;
• якщо спробувати зареєструватися залогіненому користувачу, повернеться код 403;
• якщо спробувати зареєструватися з даними користувача, який вже присутній в базі, повертається код 226 - краще замінити на 400;

Видалення користувача (відписатись)

🕒 [10:00 - 15:10]

• якщо, користувач зареєструвався на подію, то при його видаленні повертається код 500 (Internal Server Error) через constraint violation - на нього посилаються інші таблиці;
  • стратегії вирішення цієї проблеми:
    • каскадна - видаляються всі залежні записи в інших таблицях;
      • ми не можемо використати цю стратегію, бо порушується логіка: при видаленні користувача записи в залежних таблицях (visit_log) не повинні видалятись;
    • "mark not active" - треба помітити користувача, як неактивного і не видаляти його. Відповідно, треба враховувати цей параметр у SQL-запитах;

Адмінка

🕒 [15:10 - 17:35]

• /admin;
• при відсутності прав - повертається код 403;

Зауваження

Реєстрація користувача

🕒 [18:02 - 34:55]

• при реєстрації користувача треба хешувати пароль (популярний алгоритм - SHA-256 і зберігати його у хешованому вигляді (Примітка: Hash String via SHA-256 in Java));
• при реєстрації треба робити валідацію паролю (наприклад, мінімум 6 літер, наявність цифри, спец. символу);
• після реєстрації бажано виконувати авторизацію;
• треба валідувати логін, як email;
• треба використовувати OTP (задача #48);
• треба додати нову роль для користувача, який не підтвердив OTP;
  • користувач з такою роллю буде мати обмежені права, наприклад не зможе активувати підписку;
• login і logout краще перенести в UserController;

Code review

🕒 [34:55 - 50:18]

• UserRestController > registerNewSubscriber :
  • треба додати параметр confirmPassword. Цей параметр можна перевіряти на фронтенді;
  • параметри метода варто валідувати за допомогою JSR 303: Bean Validation (Примітка: Знакомство с Bean Validation API, Specification);
  • username і password краще винести в окремі класи, щоб не засмічувати анотаціями список параметрів;
  • треба переробити контроллер так, щоб він викидав Exception, якщо користувач вже існує;
  • для обробки треба використовувати Exception handler (Примітка: Exception Handling in Spring MVC);

Написання тестів

🕒 [50:18 - 1:02:43]

• спосіб розробки "згори-донизу" : тестовий метод > controller > dao
• зробити так, щоб можна було переходити на файл з датасетом DbUnit, клікнувши по його назві в аннотації (Це, мабуть, можна зробити за допомогою Unitils);

Демонстрація

• демонстрацію краще проводити на CI-сервері;