Видео

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

Все верно. В нативную добавлять нельзя. Но можно на основе нативных делать свои или подключать другие библиотеки для react native.

С другими клаудами не работал плотно. Записал в список для след видео. Посредник было бы неплохо. Звучит как хороший вариант стартапа :)

Закинул в стек следующих видео

Так как при создании аккаунта AWS вы указываете свои данные, в том числе и карты, то при достижении бесплатного лимита Лямда не перестанет работать, а продолжит. И вам за эту работу будет начислена соответствующая оплата.

@@maxd8457 Мой вопрос был не совсем в этом. Есть лимит на запросы к лямбде. Это лимит на каждую лямбду или на все, имеющиеся у аккаунта?

@@dima__rx5fw3rm1n На все))) иначе можно было бы создавать любое количество функций и заменять их при достижении лимита)

Если 10 лямбд по 100к запросов, то Вы уперлись в лимит 1М.

Их уже достаточно, чтобы миллионные проекты запускать используя эту технологию.

Если cookie не имеет флага httpOnly, то доступ к нему можно получить с помощью JavaScript на стороне клиента. Это означает, что любой скрипт, работающий на вашей странице, может читать и изменять такие cookies. Как я понял основная проблема, о которой Вы упоминаете, связана с использованием refresh токенов и их хранением на стороне клиента. 1. HTTP-Only Cookies: Когда токен сохраняется в cookie с флагом httpOnly, это означает, что JavaScript на стороне клиента не может получить к нему доступ. Это считается более безопасным подходом, так как такие cookies защищены от атак через XSS (Cross-Site Scripting), при которых злоумышленник может попытаться извлечь токены через внедренный JavaScript код. 2. Refresh Token: Refresh токены используются для получения нового access токена после истечения его срока действия, не требуя повторного ввода учетных данных пользователем. Они обычно имеют более длительный срок действия, чем access токены. 3. Безопасность: Если refresh токен хранится без httpOnly флага, он может быть украден через XSS атаки. Поэтому рекомендуется хранить его в httpOnly cookie, чтобы минимизировать риски безопасности. 4. Доступ к httpOnly Cookies на фронте: Вы правильно заметили, что при использовании httpOnly флага, фронтенд не имеет прямого доступа к cookie. Это означает, что для обновления токенов фронтенд должен отправить запрос на сервер, где сервер, распознавая httpOnly cookie, сможет обновить токен. 5. Реализация: Обычно, когда access токен истекает, фронтенд делает запрос на специальный эндпоинт сервера для обновления токена (например, /refresh-token). Сервер, получив запрос, проверяет refresh токен в httpOnly cookie и, если он действителен, отправляет обратно новый access токен (и, возможно, новый refresh токен).

@@serginyo90 я все это понимаю) у меня вопрос как мне передать cookies httponly на сервер? Какой заголовок прописать или есть какая функция?

В контексте веб-разработки, когда клиент (обычно браузер) делает запрос на сервер, он автоматически включает все соответствующие cookies (включая HTTPOnly) в заголовок запроса. Это управляется браузером, и разработчики обычно не могут контролировать это поведение. Если вам нужно настроить отправку cookies на сервер, вам нужно убедиться, что они были правильно установлены сервером, и что запросы отправляются на тот же домен (или поддомен, в зависимости от свойств cookie), для которого они были установлены. Т.е. на клиенте у Вас доступа к ней нет. Нужно установить ее на сервере в middleware или в самом ответе от сервера. Попробуйте вот так. const express = require('express'); const app = express(); app.get('/', (req, res) => { // Установка cookie res.cookie('cookieName', 'cookieValue', { maxAge: 900000, httpOnly: true }); // Отправка ответа res.send('Cookie is set'); }); app.listen(3000, () => { console.log('Server is running on port 3000'); });

@@serginyo90 передам человеку который занимается серверной частью) С моей стороны ничего не нужно прописывать? Ну кроме обычного запроса

@maxamax5695 по идеи - нет. Должны автоматически уходить, если запрос на тот же домен. Но Вы должны увидеть в ответе от сервера куку уже с включенным httpOnly

Привет!

Почему нельзя?

Ютуб удаляет комент или вы, дважды писал но его нет.

Я не удаляю комменты

При большом желании можно, но классическая схема подразумевает отправку в заголовках запроса. Так же минусом будет что токен может сохраниться в логах сервера, что особенно не безопасно при длительном сроке жизни токена. Далее текст с сайта jwt Whenever the user wants to access a protected route or resource, the user agent should send the JWT, typically in the Authorization header using the Bearer schema. The content of the header should look like the following: Authorization: Bearer <token> This can be, in certain cases, a stateless authorization mechanism. The server's protected routes will check for a valid JWT in the Authorization header, and if it's present, the user will be allowed to access protected resources. If the JWT contains the necessary data, the need to query the database for certain operations may be reduced, though this may not always be the case. (ютуб удалял из-за прямой ссылки на сайт)

@@rodigy Вы правы, классическая отправку в заголовках запроса. Но это классическая. Но есть и другие подходы. Например чтобы не отправлять JWT token в email можно сгенерировать уникальный хеш и положить в redis и связать c JWT tokenом и таким образом передавать уже этот хеш. Этот подход возможно раскрою в одном из следующих видео.

Вы наверно имели ввиду аутентификацию. А что такое Астро приложения? И чем в них аутентификации отличается от других приложений?

Здесь уже кому что нравиться. Обычно фронты плавно переходят в фулстек или в бек.

Все достаточно просто. index.html <button onclick="downloadFile()">Скачать файл</button> <script> function downloadFile() { const fileName = 'example.txt'; window.location.href = `localhost:8080/download/${fileName}`; } </script> index.js if (req.url.startsWith('/download')) { const fileName = req.url.split('/').pop(); // достаем имя файла fs.readFile(fileName, (err, data) => { if (err) { res.writeHead(404); res.end("File not found!"); return; } res.writeHead(200, { 'Content-Type': 'application/octet-stream', 'Content-Disposition': `attachment; filename="${fileName}"`, }); res.end(data); }); }

Так он уже используется активно для NFT в сфере криптовалют

@@serginyo90 тор тоже где-то используется, но до массового интернета он не дошел. А значит 99% контента будут не в торе (што грустно).

@@LedoCool1 Здесь уже время рассудит. Технология блокчейн долго существовала до Биткойна.

@@serginyo90 да, было бы хорошо если бы интернет фундаментально поменялся и обломал властолюбцев.

Благодарю, отличное уточнение.

Я имел ввиду использовать хуки, там где это имеет смысл. А не потому что это модно и 23 год на дворе. Ни одного проекта не видел где переписав на хуки стало лучше или быстрее работать приложение.

Вообще не ошибка. Хоки полезны, когда у тебя в компоненте есть портянка хуков, а потом внезапно if (!user) return null; else return (component-code со всеми данными хуков)

@d.nazaraiy В моем понимании, компоненты и бизнес-логика - это несвязанные элементы. Я поддерживаю идею выноса логики из компонентов. В случае, если проблемы с данными вызывают рендеринг сотен компонентов, это уже совершенно другой вопрос. Лично я никогда не сталкивался с ситуацией, когда хорошо написанные компоненты высшего порядка (HOC) вызывали бы проблемы с рендерингом. Тем не менее, замечаю, что каждый четвертый из пяти проектов либо дублирует функционал, либо теряет свою атомарность. P.S. Я не вижу ничего плохого в использовании ярких заголовков. Если одна и та же ошибка встречается в 80 из 100 проектов, это означает, что 80% разработчиков не уделяют должного внимания планированию архитектуры или не понимают ее в полной мере.

Не вижу смысла в вашей категоричности. Архитектуры проектов бывают разные: компонентно-ориентированные, сервис-ориентированные, смешанные и другие, возможно. В компонентно-ориентированной архитектуре бизнес-логика вполне может сидеть в компонентах. В сервисно-ориентированной архитектуре логика сидит в сервисах, которые прокидываются в компоненты разными способами и компоненты только отображают данные и дергают методы сервисов. Уровни абстракции где-то очень нужны, а где-то совсем нет. Зачем вы называете автора джуном, не учитывая многообразие архитектур проектов, с которыми вы ранее могли не работать? (Риторический вопрос)

@@serginyo90 я же говорю, что в теме вы не разобрались и только подтверждаете своим комментарием это. Вы заявляете, что бизнес-логика и компоненты не связаны, что вы поддерживаете идею выноса логики из компонентов, но при этом пытаетесь в hoc-компоненты, которые по своему принципу и должны содержать в себе бизнес-логику, при этом будучи компонентами. Перечитайте мой комментарий еще раз - я говорю о том, что нужно четко разделять компоненты визуальные от функциональных. И именно в этом и есть суть hoc. То, что вам кажется ошибкой, в большинстве случаев ошибкой не будет. Причина, по которой 4 из 5 проектов теряют свою атомарность - это изменчивость требований, которая приводит к необходимости менять архитектуру. Однако, в реальном бизнесе изменять архитектуру всего приложения или даже одного модуля - нецелесообразно каждый раз. В лучшем случае - раз в полгода-год происходит рефакторинг (архитектурный, не путать с рефакторингом кода). В остальное же время подобные несовершенства накапливаются

@@ddflruc простите, а вы не путаете, кто из нас категоричен? Автор безапеляционно заявляет, что 80% людей совершают ошибку. Я же в свою очередь говорю, что нужно думать про архитектуру, а не применение конкретных паттернов. Т.е. буквально то же самое, что написали вы. Пересмотрите видео еще раз, пожалуйста, а затем перечитайте мой комментарий. Возможно, вы измените свое мнение. То же касается "многообразия архитектур проектов, с которыми я мог не работать" - я _буквально_ в комментарии говорю, что нужно учитывать архитектуру проекта... Пожалуйста, перечитайте. И последнее. Ответ на риторический вопрос о том, почему я называю автора джуном. Во-первых, я называю так не только автора, но и всех тех, кто записывает подобные видео, а во-вторых, я делаю это, потому что это поведения джуна, не самое лучшее при чем: столкнувшись с каким-то новым "крутым" принципом, который произвел сильное впечатление или описан в "серьезном" источнике, и даже до конца в нем не разобравшись, начать тулить его везде, громогласно заявлять о том, какая невероятная штука существует и что она обязательна для всех, а кто не будет использовать - тот дурак и не лечится. Согласитесь, именно это и происходит в видео: видно, что автор _не_ _знает_, как показать на примере эффективность использования hoc, также считает создание функциональных компонент вынесением бизнес-логики из компонента, но при этом и в заголовке и в самом видео неоднократно заявляет, что все, кто не делают так - совершают ошибку. Я знаю тех, кто по техническим скилам может быть назван и мидлом, и синьйором, но при этом все еще являются вот такими же "джунами" - к сожалению, подобное мышление и поведение не проходит само по себе с опытом, а только если активно указывать, что это неправильно и зачастую недопустимо в команде.

@@d.nazaratiy Вы правильно отмечаете, что когда бизнес-логика извлекается из компонента, она может быть реализована как компонент высшего порядка. Возможно, я не совсем точно это сформулировал, но моя основная мысль заключалась в том, что простые компоненты должны оставаться простыми и нести ответственность только за свои задачи. Например, модальное окно может иметь собственное состояние, определяющее, отображается оно или нет.

а как солид связан с существованием почти полных дубликатов компонент? никак. это принцип dry (dont repeat yourself), наравне с которым существует, внезапно, принцип wet (write everything twice). оба принципа имеют свои плюсы и минусы, и хоть dry наиболее распространен, но даже при этом иногда имеет смысл держать почти полные дубликаты, вместо перегруженных универсальных компонент или абстрактных классов, особенно, если у каждого дубликата своя собственная зона ответственности и бизнес логика с любой момент может измениться кардинально. не нужно считать, что до вас над проектом работали идиоты (хотя часто это действительно так и есть) - лучше разберитесь, почему так было сделано, возможно, вы захотите сохранить этот подход и дальше PS а еще солид - это не принциП, а целых 5. И ни разу в своей жизни (17+ лет коммерческой разработки) я не видел, чтобы можно было одновременно соблюсти все 5. Ни разу.

@safarovdiyor И таких проектов много. Ни разу не видел проект где проседает производительность из-за того что есть HOC компоненты. Но много видел проектов, где наподобие поиска который Вы привели в пример. Одна и та же логика в каждом компоненте.

@@d.nazaratiy да, вы правы, солид принцип тут не причем. Скорее действительно dry принцип в моём случае

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

Возможно

Благодарю за обратную связь.

Так идея CSP чтобы без вашего ведома никто не загрузил лишний контент на сайт.

@@serginyo90 но это же можно обойти

@@im_fredy как? Вот например есть сайт www.google.com/. Как туда можно загрузить скрипт со стороннего ресурса и без моего ведома и отдать мне уже эту страницу со скриптом?

@@serginyo90к примеру Always Disable Content-Security-Policy, таких расширений много

Такое расширение юзер сам устанавливает и включает или отключает. Я же и отметил что как можно загрузить без моего ведома. Другими словами без моего согласия. А с помощью расширений конечно можно делать все что угодно, даже заходя на Гугл, показывать страницу фейсбука

У куки есть время жизни, я советую ставить около 5 секунд. Т.е. через 5 секунд она сама удалиться, поэтому дополнительно стирать не нужно.

Да, можно и так сказать

Что именно интересно в CORS? Вот вышло видео про Content Security Policy ruclips.net/video/EZU3rdpXDoE/видео.html

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

Похоже, но другое.

Все таки на столько похоже, что было бы интересно услышать разбор: "в чем разница"?

@@alexe7861 Хотя обе системы используют пиринговые сети для хранения и передачи данных, IPFS предлагает более широкий набор функций, направленных на создание децентрализованного веба, в то время как BitTorrent фокусируется на передаче файлов. Каждый файл в сети BitTorrent идентифицируется и доступен через торрент-файл, который содержит метаданные и список трекеров. Пользователи скачивают и загружают фрагменты файлов, и файлы остаются целыми только на устройствах пользователей. Нет встроенного механизма для обеспечения постоянного хранения файлов; файлы доступны, только если есть пиры, которые активно их раздают. IPFS - это распределенная система файлового хранения, которая стремится создать более постоянный, эффективный и связанный веб. IPFS использует модель содержимо-адресуемого хранения, где файлы идентифицируются по их содержанию через криптографический хеш (т.е. не будет дублировать данные). IPFS обеспечивает постоянное хранение данных, поскольку узлы могут “закреплять” данные, чтобы гарантировать их доступность в сети. IPFS позволяет не только передачу файлов, но и создание распределенных приложений, поддерживает версионирование и имеет аспекты, направленные на замену традиционного веба.

Интересно выглядит сервис.

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

@@serginyo90 государство пиринг сетей на точках обмена трафика отключит и ничего работать не будет) Я к чему - при необходимости у государства есть масса рычагов.

Не обязательно скачивать весь кеш IPFS, чтобы использовать протокол. Как правило, пользователи загружают или получают доступ только к тем файлам, которые им нужны, используя уникальные идентификаторы, известные как CID (Content Identifiers). Когда пользователь хочет получить файл из IPFS, он запрашивает его по CID, и протокол находит узлы, на которых хранится этот файл, и передает его запрашивающему узлу. Это отличается от традиционного метода загрузки полного блокчейна, как в случае с “толстым клиентом” Bitcoin, где необходимо скачать всю историю транзакций.

Хотя обе системы используют пиринговые сети для хранения и передачи данных, IPFS предлагает более широкий набор функций, направленных на создание децентрализованного веба, в то время как BitTorrent фокусируется на передаче файлов. Каждый файл в сети BitTorrent идентифицируется и доступен через торрент-файл, который содержит метаданные и список трекеров. Пользователи скачивают и загружают фрагменты файлов, и файлы остаются целыми только на устройствах пользователей. Нет встроенного механизма для обеспечения постоянного хранения файлов; файлы доступны, только если есть пиры, которые активно их раздают. IPFS - это распределенная система файлового хранения, которая стремится создать более постоянный, эффективный и связанный веб. IPFS использует модель содержимо-адресуемого хранения, где файлы идентифицируются по их содержанию через криптографический хеш (т.е. не будет дублировать данные). IPFS обеспечивает постоянное хранение данных, поскольку узлы могут “закреплять” данные, чтобы гарантировать их доступность в сети. IPFS позволяет не только передачу файлов, но и создание распределенных приложений, поддерживает версионирование и имеет аспекты, направленные на замену традиционного веба.

Нет, не совсем так. Когда вы загружаете файл в IPFS, он распределяется по сети следующим образом копия файла сохраняется на вашем устройстве, со временем его фрагменты начинают храниться на различных узлах сети IPFS, что обеспечивает его доступность и децентрализованное хранение. Файл скорее всего будет разбит на части.

тупо торрент) @@serginyo90

@@serginyo90 так, стоп, а если мне нужен целый файл для работы? Как я смогу им пользоваться, если у меня только фрагмент?

@@boenia Храниться он может частями на разных узлах. Но как только ты его запросил, он скачивается весь когда его запрашиваешь.

@@serginyo90 А, понятно, спасибо

Спасибо за обратную связь. Значит запишу видео про CSS 🙂

@@serginyo90 спасибо огромное!🤗

Видео готово ruclips.net/video/aJKdSISsp6M/видео.html

Да, конечно. Нужно создать отдельный компонент и импортировать его вместо 'react-native'. Но нужно помнить что он тогда будет выглядеть одинаково на обоих платформах. А компоненты из react-native по разному выглядит на Andorid и на iPhone.

@@serginyo90 блогадарю за ответ

Сергей, хотел бы спросить у вас, как у более опытного разработчика про такой framework как flutter, говорят, что у него очень много плюсов и мой вопрос заключается в том, полезно ли будет обратить внимание на его изучение и подготовку в случае перехода с одной среды на другую.

@@АртёмСенькевич-ы5с Обе платформы имеют свои преимущества и недостатки, и выбор между ними часто зависит от конкретных требований проекта и предпочтений разработчика. • Flutter: Использует Dart, разработан Google • React Native: Использует JavaScript, разработан Facebook. UI-компоненты: • Flutter: Предоставляет обширный набор настраиваемых виджетов для создания сложных пользовательских интерфейсов. • React Native: Предоставляет базовые компоненты, и часто требует сторонних библиотек для дополнительных функций. Если есть опыт с Реактом, советую попробовать React Native. Это будет самый быстрый старт.

Супер. Спасибо за обратную связь

В этом плейлесте не будет. Но если будет много запросов на Гриды, то могу записать отдельное видео.