Как мы отказались от Vue.js ради надёжности: история одного модуля авторизации

Контекст: крупный проект и сквозная авторизация

Нашу команду пригласили на крупный проект, где мы отвечали за модуль сквозной авторизации — единую точку входа для всех остальных сервисов экосистемы.

Стек проекта:

• Backend: Laravel

• Frontend: Vue.js

• База данных: MySQL

• Очереди: RabbitMQ

• Аутентификация: SAML

Наша роль казалась стандартной: обеспечить бесшовный вход пользователей во все сервисы через единый модуль. Всё работало — до определённого момента.

Проблема: авторизация зацикливается

Начали поступать регулярные инциденты: при попытке авторизации страницы зацикливались, и вход не происходил.

Пользователи жаловались на:

• бесконечные редиректы;

• зависание на экране входа;

• невозможность завершить авторизацию.

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

Диагностика: кто на самом деле «ломал» авторизацию

Мы развернули расширенное логирование, собрали данные с фронта и бэкенда, проанализировали паттерны обращений. И выяснилось неочевидное.

Ряд пользователей работал со старых устройств и старых браузеров. Само по себе это не проблема — многие сервисы поддерживают legacy. Но у этих пользователей был установлен корпоративный софт безопасности со специфическими настройками, который был обязательным условием от службы безопасности компании.

Как это работало:

1. Браузер загружал страницу авторизации с Vue.js.

2. Внутренний софт безопасности анализировал трафик и поведение страницы.

3. Из-за особенностей работы Vue.js (динамическая загрузка, асинхронные запросы, перерисовка DOM) софт неверно интерпретировал активность.

4. В ответ он начинал блокировать или повторно инициировать запросы.

5. Каждый такой запрос уходил на сервер — и это повторялось многократно.

Результат: сотни пользователей с таким софтом фактически устраивали распределённый DDoS на наш сервис авторизации — не по злому умыслу, а из-за ложной реакции защитного ПО.

Проблема была не в нагрузке как таковой. Проблема была в том, что современный JS-фронтенд конфликтовал с корпоративными системами безопасности на стороне клиента.

Решение: минимализм вместо современности

Мы приняли непопулярное, но единственно верное в этой ситуации решение: перевести сервис авторизации на максимально простой стек.

Что использовали:

• HTML — статичная разметка без динамической генерации.

• CSS — обычные стили, без фреймворков и препроцессоров.

• Нативный JavaScript — без библиотек, без фреймворков, без сборщиков.

Что убрали:

• Vue.js и всю его экосистему.

• Асинхронную загрузку компонентов.

• SPA-роутинг.

• Лишние XHR-запросы на этапе авторизации.

Ключевой принцип: страница авторизации должна быть настолько простой, чтобы её не «испугался» ни один браузер и ни одна система безопасности.

Результат: ноль инцидентов

После перехода на простой стек:

• Не было ни одного инцидента, связанного с работой нашего сервиса.

• Не было конфликтов с корпоративным софтом безопасности.

• Не было зацикливаний и бесконечных редиректов.

• Нагрузка на сервер авторизации снизилась кратно.

При этом функциональность не пострадала: пользователи по-прежнему проходят сквозную авторизацию во все сервисы экосистемы.

Что мы вынесли из этой истории

1. «Современный стек» — не всегда правильный выбор

Vue.js, React и другие фреймворки отлично работают для продукта, где пользователь — обычный человек с современным браузером. Но для критичного модуля авторизации в корпоративной среде приоритет — не скорость разработки, а предсказуемость и совместимость.

2. Пользователь не всегда виноват

Когда поступают жалобы на «старые устройства», легко списать проблему на пользователя. Но настоящая причина часто глубже: на стыке legacy-браузеров и современного фронтенда рождаются конфликты, которые не видны в тестовой среде.

3. Логирование — основа диагностики

Без детального логирования мы бы никогда не увидели, что проблема не в нагрузке, а в паттерне запросов. Логи показали: запросы шли не от «злоумышленников», а от реальных пользователей с защитным ПО.

4. Иногда «откат» — это прогресс

Отказ от Vue.js в пользу нативного JS выглядел как шаг назад. По факту это было инженерное решение, продиктованное реальностью эксплуатации, а не модой.

Заключеение

Эта история — не про то, что Vue.js плохой. Она про то, что архитектурные решения нужно принимать под контекст, а не под тренды.

Для модуля авторизации в крупной корпоративной экосистеме минимализм оказался надёжнее современности. И это тот случай, когда «проще» означает «лучше».