да, const data = await response.json()

А json валидный? Вообще надо бы обернуть это в try, catch и делать через componentDidMount = async () => { try { const response = await fetch(url); const data = await response.json(); this.setState({data}); } catch (e) { console.error(e); } }

А json валидный? Вообще надо бы обернуть это в try, catch и делать через componentDidMount = async () => { try { const response = await fetch(url); const data = await response.json(); this.setState({data}); } catch (e) { console.error(e); } }

Есть какие-то пруфы, исследования или это наброс ради наброса?

Гуглите вацап)

Пруфы? https://medium.com/intrinsic/compromised-npm-package-event-stream-d47d08605502 не совсем к утверждению "js - дыра", но и изначальный вопрос был не в js, а в приложении на RN. И вот ссылка выше напрямую касается js части. Надо понимать, что мы ставим себе на комп, на CI и запускаем там, впаковываем в приложение и отдаем пользователям огромное кол-во чужого непроверенного кода.

это не аргумент

По информации WhatsApp, хакеры для установки вредоносных программ осуществляли голосовые звонки на устройство жертвы, пишет FT. Уязвимости были подвержены как смартфоны с Android, так и iOS. Для установки вредоносного программного обеспечения (ПО) пользователям даже не нужно было отвечать на звонки. Данные о входящем звонке не отображались в списке входящих вызовов.

Это таки вопрос к экосистеме и подходе. У нас в бою нет либ, с исходниками которых мы не ознакомились, но все равно это не 100% защита. Опять же есть сервисы типа snyk.io, которые по lock файлу мониторят уязвимости. Наброс же был про то, что жс дыра из-за eval, за который имхо в 99% случаев надо бить по рукам, но так можно сказать про любой ЯП. Можно нажаловаться на ручное управление памятью, и т.п

А, к слову, сегодня утром обнаружил (с кем делился, пока не подсказывайте). На тему js и безопасности, правда весьма косвенно (всё же движки проверяют)... Как вы думаете, выражение Date.parse(d) === new Date(d).valueOf() истинно для значений d, которые не NaN после парсинга?

Js ни при чем вообще. И рн в частности. Проблема системная и гораздо повыше в иерархии

Разве он не должен привести к единому типу для сравнения? Тут получается он сравнивает число и строку…

Разве он не должен привести к единому типу для сравнения? Тут получается он сравнивает число и строку…

вот правильное

Не, про eval ничего не могу сказать - не использую, да и не так часто его видел в последнее время (есть же new Function - шутка). Но вот react-native@0.59.8 зависит прямо или косвенно от 422 пакетов (а ведь там ещё модули нужны). Вы их все прям сами просмотрели? А вот npm считает про эту версию RN, что: found 28 vulnerabilities (14 low, 14 high)

Это таки вопрос к экосистеме и подходе. У нас в бою нет либ, с исходниками которых мы не ознакомились, но все равно это не 100% защита. Опять же есть сервисы типа snyk.io, которые по lock файлу мониторят уязвимости. Наброс же был про то, что жс дыра из-за eval, за который имхо в 99% случаев надо бить по рукам, но так можно сказать про любой ЯП. Можно нажаловаться на ручное управление памятью, и т.п

Date.parse() возвращает число, new Date().valueOf() тоже число

Не, про eval ничего не могу сказать - не использую, да и не так часто его видел в последнее время (есть же new Function - шутка). Но вот react-native@0.59.8 зависит прямо или косвенно от 422 пакетов (а ведь там ещё модули нужны). Вы их все прям сами просмотрели? А вот npm считает про эту версию RN, что: found 28 vulnerabilities (14 low, 14 high)

Так ведь valueOf работает с getTime, почему в примере вызывается именно он? Просто я хз как сейчас с датами, но раньше дебажить их было грустно, потому что V8 и JSC работали по разному с ними

Вот это да, и даже не известно кто и как всё это сопровождает, хммм... Точно - сообщество

С датами ситуация примерно такая же как с безопасностью только на 20 лет старее)))

А теперь интересное. Возьмем d = '2018-05-16T22:00:00.123456789Z', кто как думает, вот это останется верным: Date.parse(d) === new Date(d).valueOf()?

А с нативными либами таких проблем разве нет? 🤔

А теперь интересное. Возьмем d = '2018-05-16T22:00:00.123456789Z', кто как думает, вот это останется верным: Date.parse(d) === new Date(d).valueOf()?

Не могу сказать точно, но думаю что есть. Вот почему на C или C++ сложно писать безопасный и качественный код, потому что зависимости от легаси там везде, что приходится велосипеды создавать, вот и js взял эту "фичу" от своего прадеда

А ещё на сях не было принципа кисс долгое время, а вот у хаскела был, но этот яп мало кому понравился, а жаль

А какое отношение кисс к яп имеет?)

На глибси посмотри

Ну это легаси)

Да, а не должно?

Знач нормально)

Мне тоже казалось что выражение Date.parse(d) === new Date(d).valueOf() должно быть истинно, это как бы следует из нормальной человеческой логики. Ведь конструктор объекта Date, если у него на входе строка по идее должен сделать то же, что и Date.parse. Но как всегда дьявол в деталях. В JS максимальная точность Date - единицы миллисекунд. И v8 эту точность устанавливает в алгоритме парсинга, поэтому Date.parse возвращает целое число всегда, а JSC - нет и в RN Date.parse('2018-05-16T22:00:00.123456789Z') вернет 1526508000123.4568 😉

Большинство крупных проектов пытались отказаться от неё, но было сложно ибо все уже написано, а одна либа зависит от другой и т.д.

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

Забавно, значит проблемы различия движков в работе с датами, как я писал выше остались на месте

Мне тоже казалось что выражение Date.parse(d) === new Date(d).valueOf() должно быть истинно, это как бы следует из нормальной человеческой логики. Ведь конструктор объекта Date, если у него на входе строка по идее должен сделать то же, что и Date.parse. Но как всегда дьявол в деталях. В JS максимальная точность Date - единицы миллисекунд. И v8 эту точность устанавливает в алгоритме парсинга, поэтому Date.parse возвращает целое число всегда, а JSC - нет и в RN Date.parse('2018-05-16T22:00:00.123456789Z') вернет 1526508000123.4568 😉

Вот типичные рассуждения обгоревшего человека. Я такой же. Все такие же)

как ты вообще это откопал?))

В Go, который у нас на сервере, время с точностью до наносекунд и он это присылал иногда, я удивился и полез смотреть как мне это парсить в исходники v8, а потом в jsc... и увидел там несоответствие, проверил в safari и node.js - подтвердилось.

Понимаю, нужно проверить релизную сборку, посмотреть параметры запуска xcodebuild и возможно попробовать с теми же параметрами из xcode сбилдить

Хмм, запустил на девайсе из xcode - и опять это.. You attempted to use a firebase module that's not installed natively on your iOS project by calling firebase.messaging(). Ensure you have the required Firebase iOS SDK pod for this module included in your Podfile, in this instance confirm you've added "pod 'Firebase/Messaging'" to your Podfile See http://invertase.link/ios for full setup instructions.