Вы наверняка слышали про Rspack — альтернатива Webpack, но на Rust и с совместимостью по плагинам и конфигам.

Приятно знать, что такие быстрые проекты развиваются и уже имеют весьма крутую экосистему.

19 марта релизнулся Rsdoctor.
По сути это аналог Statoscope, позволяющий дебажить и профилировать сборку. Особенно полезно в больших и сложных проектах, чтобы понять откуда и что заимпортировано.

Максимально актуально в связи с переездом экосистему на ESM, в ситуациях, когда два пакета имеют общую зависимость, но один пакет получил CJS версию, а другой ESM, в итоге в бандле две версии, странные плавающие баги и подобное.

https://rsdoctor.dev/blog/release/release-note-1_0

Из интересных проектов использующих Rspack экосистему — Lynx

Собирает React проект в Native приложения для мобилок.
Из любопытного: имеет кастомные директивы "background only" и "main thread" для выполнения функций в разных потоках.

https://lynxjs.org/react

Очень любопытный проект

Ходит на сайт с девтлузами React и строит граф зависимостей компонентов на странице.

К сожалению, исходники закрыты, проект на ранней экспериментальной фазе, но потыкать оказалось любопытно. Не требует установки.

https://react-explorer.com/

В 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 (
    <div>
      <h1>Post: {postId}</h1>
      <Suspense fallback={<div>Loading post...</div>}>
        <Post postId={postId} />
      </Suspense>
    </div>
  );
}

Сомнительное решение, на мой взгляд, но в случае простых веб-страниц может действительно облегчить работу с отображением данных.

https://aurorascharff.no/posts/avoiding-server-component-waterfall-fetching-with-react-19-cache/

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

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

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

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

Уязвимости в 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, поэтому для фикса нам нужно было апнуть минорную версию, но это уже другая история.

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

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

Но вот не задача, почему то (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

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

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

Не понимаю я людей, которые считают, что мы одни во вселенной.

Вот смотришь на такие фото, там сотни галактик, и очень давно и далеко.
Мы, как вид, не можем выяснить, есть ли жизнь на другой планете в пределах нашей собственной галактики, а так уверенно утверждать про целую вселенную…

То, что мы не нашли, еще не значит, что жизни нет.
Я почти уверен, что вселенная полна жизни в самых разных формах.

atomic-router v0.12

- Экспортирован тип HistoryRouter
- Минимальная версия Node.JS поднята до v18.x

atomic-router-react v0.12

- Минимальная версия Node.JS поднята до v18.x
- Минимальная версия atomic-router теперь v0.12.0
- Удален atomic-router-react/scope, так как effector-react теперь работает со Scope из коробки
- Добавлен параметр replace в Link — <Link replace>
- Добавлена поддержка React 19

P.S.
С точки зрения поведения брейкингов не было.
Все найденные баги репортите в репозитории пожалуйста.
В ближайшее время занимаюсь фиксами всех уже найденных.

Parcel переезжает на Rust

https://parceljs.org/blog/v2-15-0