Еще один день, когда приложение ChatGPT просто выкидывает записанный войс, потому что транскрибировать не удалось.

Гениальное решение, ну раз юзер записал войс, значит сама запись больше не нужна, не взирая на возможные ошибки распознавания… гении, не иначе

Блокировки, блокировки, блокировочки...

Значит, бывает такая история, что сидишь ты понимаешь, на хорошем и дешевом хостинге и крутиш свои кубернейтесы. И все тебе збс и устраивает.

Но вот не задача, почему то (sarcasm) подсети этого хостинга начинают блочить провайдеры...

Смачно выругавшись начинаем искать варианты:

1. Переехать значит на православный хостинг и платить x100500 деняг
2. Купить на православном хостинге VPS, поставить там nginx в режиме stream и надеяться, что хостинг не заблокируют на уровне магистрали.

Для тех кто выбрал второй вариант, все просто.

1. Ставим nginx с поддержкой stream
2. Добавляем в nginx.conf
...
stream {
upstream k8s_https {
server ваш_ip:443;
}

server {
listen 443;
proxy_pass k8s_https;
}
}
...
В отличие от стандартного http {} блока, stream работает на уровне TCP, а не HTTP.
Он не трогает заголовки, не читает Host, не парсит User-Agent
Он просто берёт входящий TLS-трафик и тупо прокидывает его дальше.

При этом это работает охуительно быстро, в отличии от обычного proxy_pass

Никакого overhead, никакой нагрузки на CPU, ничего не разбирается, не кешируется и не мутируется.
Это как туннель, только без OpenVPN и танцев с бубном.


BEARlogin dev — подпишись!
#блокировки #proxy #devops

Уязвимости в NextJS

Я думаю уже почти все слышали про уязвимость в NextJS, которая позволяет при запросах обходить миддлевары, и например, пропускать обработку авторизационных токенов и прочие серверные проверки. Уязвимость очень проста в эксплуатации, достаточно прокинуть http-заголовок x-middleware-subrequest, которая пропускает указанные миддлевары. Подробнее почитать можно в блоге Рашида Алама.

Наш проект это не затронуло, так как мы не смогли в свое время завести в нашей инфре стабильную работу миддлевар. Но пару месяцев назад мы столкнулись с другой уязвимостью на основе «cache poisoning», которая не получила столь бурную реакцию в интернете, но в нашем случае тоже могла бы привести к довольно критичным последствиям.

Cache poisoning (дословно, отравление кэша) - это атака, при которой обычным пользователям отображается вредоносный ответ на основе манипуляций с веб-сервером и кэшем.

Кэш позволяет отдавать идентичный ответ пользователю, который сделал аналогичный запрос. Как понять, что запрос аналогичный? У запросов должен быть одинаковый кэш-ключ, который обычно формируется на основе различных компонентов: тип запроса, хост, pathname, некоторые http-заголовки (конечно этих параметров может быть намного больше). Если ключ совпадает, то отдается сохраненный результат из кэша, если нет - то запрос начинает обрабатываться сервером.

Но есть компоненты, которые никак не влияют на ключ кэша (например какие-нибудь http-заголовки). И если какой-нибудь из этих компонентов может повлиять на ответ, то можно подложить отравленный результат в кэш, который будет возвращаться уже обычным пользователям.

Вот и мы нарвались на такую уязвимость в нексте (CVE-2024-46982). Если кратко, у NextJS в рамках page router-а есть режим SSR через функцию getServerSideProps, которая подготавливает данные в формате JSON для страницы. Для этого некст при заходе на страницу отправляет запрос по пути /_next/data/.... Но есть внутренний query-параметр ?__nextDataReq=1, при добавлении которого к странице возвращается только JSON-данные для нее. И этот query-параметр не является частью ключа для кэша. Условно https://a.com и https://a.com/?__nextDataReq=1 будут иметь один ключ. Если результат второго запроса сложить в кэш, то у всех пользователей вместо главной страницы будет открываться JSON с данными.

Сам по себе getServerSideProps является динамическим и в кэш ничего не складывает. Но еще есть внутренний http-заголовок x-now-route-matches, "включающий" SSG (server side generation) режим некста, который складывает результаты в кэш. Понимаете к чему я веду? Уязвимость заключается именно в этом и с помощью комбинации ?__nextDataReq=1 + x-now-route-matches и одного запроса можно сломать любую динамическую страницу приложения, путем складывания в кэш JSON-данных для страницы и отдачи их вместо html-контента.

Более того, в этот JSON часто попадают значения http-заголовков, поэтому в него можно положить произвольный текст. А с учетом того, что запросы продолжают отдавать content-type равный text/html, то получаем еще и XSS абсолютно для всех пользователей, которые просто зайдут на страницу.

Подробнее про это можете почитать в блоге все того же профессора Рашида https://zhero-web-sec.github.io/research-and-things/nextjs-cache-and-chains-the-stale-elixir

Уязвимость уже была пофикшена в новых версиях NextJS, поэтому для фикса нам нужно было апнуть минорную версию, но это уже другая история.

Насколько мне известно, появление поиска в ChatGPT, Google Grounding Answers, Claude Web Search сильно меняет рынок поисковиков.

Все больше пользователей ищут ответы на свои вопросы через AI, не утруждая себя подбором ключевых слов в Google.

Но насколько поиск через AI действительно лучше?
Автор проводит ревью существующих инструментов, рассуждает, как можно улучшить текущий поиск и какие у него есть проблемы.

https://paulstamatiou.com/browse-no-more

Анализировать зависимости NPM-пакетов можно еще с помощью Node Modules Inspector

Умеет показывать не только граф зависимостей, но и ESM/CJS поддержку, использование транзитивных зависимостей, место на диске.

https://node-modules.dev/

В Next.js 15 убрали автоматическое кеширование fetch().
Перестать манкипатчить стандартные методы — движение в верном направлении.

Взамен появился "use cache":
https://nextjs.org/docs/app/api-reference/directives/use-cache

А также cache() в React 19:
https://react.dev/reference/react/cache

А статья от Авроры показывает как использовать cache() для мемоизации вызовов экшенов


// When using cache(), the return value can be cached/memoized per render across multiple server components
const getComments = cache(async (postId: string) => {
return fetchedData // actual implementation here
});


Но использовать его можно только в компонентах, еще и без await:


export default async function PostPage({ params }: { params: Promise<{ postId: string }> }) {
const { postId } = await params;

// Prefetch the comments, but don't await the promise, so it doesn't block rendering
getComments(postId);

return (
}>