Sentry и Adblock: обходим блокировки

Sentry по праву является одним из самых популярных open-source приложений для трекинга ошибок. Сотни миллиардов сообщений ежемесячно, миллионы разработчиков и тысячи команд используют инструмент для улучшения качества продуктов. Sentry использует крайне продвинутый механизм track trace, который в купе с обширным контекстом позволяет логгировать множество идентификационных данных пользователя (IP-адреса, версии браузеров, информация об ОС и др.), что крайне может не нравиться приверженцам приватности в сети. Итогом этого недовольства стала блокировка запросов большинством популярных adblock-расширений ко всем версиям Sentry (cloud & self-hosted).

EasyList & EasyPrivacy

Стоит напомнить откуда блокировщики рекламы берут информацию: помимо пользовательских правил, большинство (если не все) расширения используют открытые списки фильтров. Самым популярный и крупный из них Easylist, позиционирующийся как глобальный список фильтров для блокировки навязчивых элементов на странице и содержащий уже более 55 тысяч правил на момент написания статьи. Существуют также региональные списки правил для более точечных блокировок и продвинутые фильтры для скрытия блоков об использовании adblock, уведомлений о cookies, GDPR и тд (полный список). Но нас интересует второй по популярности список правил, который по умолчанию включен в блокировщиках. Речь идет об EasyPrivacy - это набор правил для блокировки отслеживающих скриптов. Именно он мешает сообщениям об ошибках попадать в Sentry.

Self-hosted или Relay не помогут

Если посмотреть на правила EasyList, то станет очевидно, что обычная смена домена не решит проблему: правила затрагивают не домены, а ключевые аргументы Sentry. Это означает, что сколько бы мы не меняли домены и версии, результат останется тем же.

Так как список правил представляет из себя множество URL с регулярными выражениями, то решение назревает довольно быстро: отправлять необходимые данные внутри тела запроса. И да, разработчики Sentry уже предоставляют такой механизм в стандартной SDK под названием tunnel.

Свет в конце тоннеля

Опция туннелирования отключает передачу GET-параметров (sentry_key и sentry_session) на стороне клиента и переносит весь payload в тело POST-запроса. Во избежание более строгих блокировок Sentry не предоставляет обработчик подобных запросов на стороне сервера. Это означает, что необходимо самостоятельно написать эндпоинт, принимающий данные в новом формате, после чего пересылать в Sentry в уже привычном ему формате.

Используем новый способ

Так как разработчики великодушно показали пример реализации прокси-сервера на PHP, то не составляет никакого труда сделать это нормально его переписать и докеризировать. Для этого я выбрал Python и AIOHTTP. Таким образом, конфигурация прокси-сервера сводится к следующему:

• Запуск докер-образа

docker run -t -p 8080:8080 k0t3n/sentry-tunnel

• Проксирование запросов с вашего веб-сервера. Для примера возьмем NGINX

...

location /tunnel {
    proxy_pass <http://127.0.0.1:8080>;
}

...

• Конфигурирование SDK

...

Sentry.init({
  app,
  dsn: '<https://<public_key>@o000000.ingest.sentry.io/><project_id>',
  tunnel: '/tunnel',
    ...
})

...

Всё, теперь ваши сообщения об ошибках будут чаще попадать в Sentry. Прокси-сервер можно найти на Github. Буду рад вкладам и замечаниям.

Спасибо!