Дякую за ваші відоси. У вас добре виходить створювати якусь таку не примусову атмосферу та цікаво подати матеріал, котрий зазвичай дуже нудний і скіпається 🔥
Дякую. Зараз прохожу курс CS50 комп'ютер сайнс, і тому передивлявся твої відео. Коли дивився перший раз, думав, що все зрозумів, але все зрозумів я зараз, а не тоді :D
Лайк ще до перегляду) Надзвичайго корисні та цікаві відео ще й українською! Дуже дякую!) Так як не працюю із js, окремо дякую що ваші відео фокусуються не на певній мові програмування та технології, а на інженерію вцілому! В одному з відео ви розказували за алгоритми, а чи планується продовження данної рубрики? Дякую)
Дякую за детальний оляд. Відкрив для себе деякі речі із іншої сторони. Також було б круто в описі до відео отримувати рекомендовану вами літературу/джерела по темі відео.
Дякую 🤝🏻 Той випадок коли вмикав перегляд з думкою повторити те що знаю, аж раптом помітив для себе дещо нове. Завжди подобаються подібні ситуації, бо відчуваєш більше прибутку ніж очікував. Крім того, це значний плюс в характеристику вас як автора матеріалу: свідчить про те що не повторюєте примітивні пояснення яких тисячі в мережі👏🏻
Дякую! У мене Kubuntu Linux. Термінал Kuake (тільки під KDE), під Gnome є Guake. Відносно MacOs, то я користуюся iTerm2, який теж можна налаштувати, щоб випадав зверху по комбінації клавіш
Дякую за відповідь! Можу я задати ще кілька запитань не по темі відео? - Чи плануєте Ви окреме відео про те як працює HTTPS у середині? - Що ви думаєте про вивчення мов програмування, які не потрібні у роботі кожен день? Наприклад вивчення мови Rust коли працюєш фронтєндом? - Взагалі що ви думаєте про мову Rust? Вона варта вивчення? Чи замінить вона колись С++?
Дякую за відео. Але дещо неясно, ви сказали що base64 використовується для кодування бінарних данних. І навіть показали як воно кодується. Але потім, в прикладі з jwt ми беремо base64 кодований блок і через команду echo ... я очікую отримати бінарні дані а термінал мені виводить читаємий json. Тобто ми закодували текст в base64 а не бінарні дані. Тобто base64 використовується не тільки для кодування бінарних даних? Це неспівпадіння не дає повної картини - чи може там є якась проміжна механіка типу json текст представлений в бінарному вигляді і цей бінарний вигляд потім кодується в base64....
Ми можемо розглядати текстові дані, як підмножину бінарних даних, оскільки вони зберігаються в одиничках й нуликах (але звісно, що одні й ті самі текстові данні можуть бути представлені в різному бінарному кодуванні). Просто особливість бінарних даних в тому, що вони не завжди мають текстову репрезентацію. Відносно того, чому термінал виводить читаємий JSON, то причина в тому, що термінал очікуює текстові дані в певному кодуванні (наприклад UTF-8) й бінарні дані, яки ми отримали після декодування base64 й є UTF-8, тому термінал їх успішно представляє у вигляді тексту. Аби у нас термінал очікував UTF-16 (який не є сумісним з ASCII), то він не зміг би показати UTF-8 дані як текст
На 9 хв розповідали, що використовуючи 6 біт можна закодувати 64 символи. Виходить один текстовий символ, наприклад А має 6 біт, чому коли ми його відправляємо, ви кажете що він буде займати 8 біт? ps: дуже круте пояснення непростих тем, дякую вам
Так й є. У нас є текстове 8-ми бітне кодування. Кожен символ - 1 байт. Коли кодуємо в base64, то ми кожні 6 біт представляємо одним з 64 символів з набору base64 й потім цей символ передаємо, як символ 8бітного ASCII кодування (чи сумісного) й відповідно він починає займати 8 біт хоча репрезентує 6 біт
То який сенс base64, якщо він тільки збільшує розмір файлу? Не легше просто передати вихідний файл? А також, який сенс auth і jwt, добре, jwt я ще бачив відео про два ключі(доступу і оновлення) але по суті, всеодно знадобиться збереження цих даних в бд за ID, і відправка цього ID, на сторону клієнта, а потім ще паритися з відновленням і заміною цих jwt & IDFromDB, це я ще не кажу про доступ з декількох пристроїв, а також захисту серверу від DDos атак з перебором ID, а якщо ID використовується з якимось алгоритмом то взагалі пиши пропало. Із цього випливає, що JWT & auth додає тільки поля з даними і кодує під base64(чи що там). Чи є реально захищені варіанти реалізації наприклад сесій і авторизації в додатку, окрім встановлення express-rate-limit?
Так, кодувати бінарні дані у вигляді тексту не завжди потрібно, але часто використовують, бо багато текстових протоколів. Наприклад JWT має підпис, який бінарний, а хедери в http1.1 розділені " " й в бінарних даних може бути такий байт й відповідно буде битий запит. Але якщо його закодувати в base64, то проблеми немає. Те саме стосується й картинок в CSS (їх можна тягнути окремим файлом, але якщо це іконка, то й не треба робити запиту додаткового, наприклад). Часом basе64 корисний, коли треба в логі записати якісь бінарні дані, а логи це зазвичай текстові строки. Відносно використання JWT, то основна користь в тому, що це не просто рандомний набір символоів, а якісь дані, яки приходять й яким можна довіряти, бо вони підписані. Також в JWT підпис можна робити приватним ключем, а перевіряти публічним. Тобто інші системи можуть перевірити, що запит прийшов від певного юзера, але їм достатньо мати для цього лише публічний ключ. Але так, сесії можна зробити просто по токену й без JWT, але проблема оновлення залишається. Звучить, як гарна тема для відео :) Відносно захисту від перебору, то rate limiting може працювати (можна обмежувати кількість запитів з одного айпі, чи можна обмежувати перебори для одного акаунту та інші)
В JWT, наприклад. Чи картинку в CSS, чи HTML вкласти, щоб не тягнути окремо. Basic auth використовує base64, щоб можна було передати логін й пароль. Часом треба якісь бінарні дані просто записати в лог-файл або покласти а конфіг. Багато текстових протоколів (той самий HTTP, атачменти в пошті, ключі шифрування для того самого ssh) й форматів існує й часом в них треба вкласти бінарні дані
Коли побачив що user and password ми передаємо по мережі, вони є закодовані то був трішки шокований, і тут відразу питання що https нам дійсно дає секнюрність і ці дані не можуть бути перехвачені? І чому них не можна шифрувати?
Так, вся безпека веб будується на базі https. Чи можна перехопити дані при використанні https - так, але при певних умовах, при підміні сертифікату сервера. Щоб замінений сертифікат пройшов перевірку, він має бути підписаний приватним ключем центра сертифікації для якого на клієнті є публічний ключ. Тобто, якщо вам хтось встановитить сертифікат (в якому публічний ключ) певного центру сертифікації на комп, то цей центр сертифікації зможе генерувати сертифікати для будь-якого сайту. Така схема буває на корпоративних ноутах, щоб моніторити шифруванний трафік. Відносно Basic Auth, то там ще є проблема з CSRF. Ну й ще є Digest Auth, який вже не передає пароль у відкритому вигляді, але теж має власні проблеми
https і дає рівень захисту шифруванням, це посуті надбудова над http це більш універсальне рішення, ніж додавати шифрування для особливих складових http
Шукав пояснення base64 англійською, але виявилося, що найкраще пояснення зробили українською)
Кайфую від інформативності і якості подання. Крутий формат подання. Дякую
Дякую за ваші відоси. У вас добре виходить створювати якусь таку не примусову атмосферу та цікаво подати матеріал, котрий зазвичай дуже нудний і скіпається 🔥
просто супер корисно! дуже дуже дякую. лише не зрозумів ро падінги, йду гуглити. Дуже дякую ще раз!
Вирішив не ускладнювати, бо не всі Base64 конвертори їх вимагають. Але це частина стандарту 🙂
За base64url дякую ❤❤❤
Дуже було цікаво. Виявляється так все просто
Ви чудово пояснили основи та практичні застосування цього кодування. Дякую за корисний контент!
Дякую. Зараз прохожу курс CS50 комп'ютер сайнс, і тому передивлявся твої відео. Коли дивився перший раз, думав, що все зрозумів, але все зрозумів я зараз, а не тоді :D
Лайк ще до перегляду)
Надзвичайго корисні та цікаві відео ще й українською! Дуже дякую!)
Так як не працюю із js, окремо дякую що ваші відео фокусуються не на певній мові програмування та технології, а на інженерію вцілому!
В одному з відео ви розказували за алгоритми, а чи планується продовження данної рубрики? Дякую)
Дякую! Так, по алгоритмах точно буде ще не одне відео 🙂
Дякую, було справді корисно.
Найкраще пояснення яке я бачив, ще й українською. Дуже дякую!
це відео дуже зрозуміло пояснює, як base64 використовується для кодування даних. дуже корисний матеріал.
Дякую. Дуже якісне й корисне відео.
Під час перегляду вже не вперше помічаю, що знаю, про що йтиметься далі, але не через те, що це повтор інформації, а через логічність
Дякую, використовував base, але не знав про таке застосування 🔥🔥🔥
Дуже цікаво!
Коментар в підтримку. Топ контент =)
Дякую за детальний оляд.
Відкрив для себе деякі речі із іншої сторони.
Також було б круто в описі до відео отримувати рекомендовану вами літературу/джерела по темі відео.
Дуже дякую. Вельми корисна та унікальна інформація.
Дуже класно все пояснено. Дякую за працю та за якісний український контент!
В молодости изучал циклы в ассемблере на примере base64
Круто! Давай ще!)
Інформативно!
Дякую!
Кращий канал який я знайшов за 2023)
Дякую 🤝🏻 Той випадок коли вмикав перегляд з думкою повторити те що знаю, аж раптом помітив для себе дещо нове. Завжди подобаються подібні ситуації, бо відчуваєш більше прибутку ніж очікував. Крім того, це значний плюс в характеристику вас як автора матеріалу: свідчить про те що не повторюєте примітивні пояснення яких тисячі в мережі👏🏻
Чудовий контент, дякую
Супер. Дякую. 👍
Дуже дякую! Чудова подача та супер корисний контент!
Підкажіть, будьласка, який у Вас термінал? Та чи є такий для МакОС?
Дякую! У мене Kubuntu Linux. Термінал Kuake (тільки під KDE), під Gnome є Guake. Відносно MacOs, то я користуюся iTerm2, який теж можна налаштувати, щоб випадав зверху по комбінації клавіш
Дякую за відповідь!
Можу я задати ще кілька запитань не по темі відео?
- Чи плануєте Ви окреме відео про те як працює HTTPS у середині?
- Що ви думаєте про вивчення мов програмування, які не потрібні у роботі кожен день? Наприклад вивчення мови Rust коли працюєш фронтєндом?
- Взагалі що ви думаєте про мову Rust? Вона варта вивчення? Чи замінить вона колись С++?
Коротко і по суті
Шкода що не побачив цього відео рік назад
Like
Дякую за відео. Але дещо неясно, ви сказали що base64 використовується для кодування бінарних данних. І навіть показали як воно кодується. Але потім, в прикладі з jwt ми беремо base64 кодований блок і через команду echo ... я очікую отримати бінарні дані а термінал мені виводить читаємий json. Тобто ми закодували текст в base64 а не бінарні дані. Тобто base64 використовується не тільки для кодування бінарних даних? Це неспівпадіння не дає повної картини - чи може там є якась проміжна механіка типу json текст представлений в бінарному вигляді і цей бінарний вигляд потім кодується в base64....
Ми можемо розглядати текстові дані, як підмножину бінарних даних, оскільки вони зберігаються в одиничках й нуликах (але звісно, що одні й ті самі текстові данні можуть бути представлені в різному бінарному кодуванні). Просто особливість бінарних даних в тому, що вони не завжди мають текстову репрезентацію.
Відносно того, чому термінал виводить читаємий JSON, то причина в тому, що термінал очікуює текстові дані в певному кодуванні (наприклад UTF-8) й бінарні дані, яки ми отримали після декодування base64 й є UTF-8, тому термінал їх успішно представляє у вигляді тексту. Аби у нас термінал очікував UTF-16 (який не є сумісним з ASCII), то він не зміг би показати UTF-8 дані як текст
топчик
На 9 хв розповідали, що використовуючи 6 біт можна закодувати 64 символи. Виходить один текстовий символ, наприклад А має 6 біт, чому коли ми його відправляємо, ви кажете що він буде займати 8 біт?
ps: дуже круте пояснення непростих тем, дякую вам
Так й є. У нас є текстове 8-ми бітне кодування. Кожен символ - 1 байт. Коли кодуємо в base64, то ми кожні 6 біт представляємо одним з 64 символів з набору base64 й потім цей символ передаємо, як символ 8бітного ASCII кодування (чи сумісного) й відповідно він починає займати 8 біт хоча репрезентує 6 біт
То який сенс base64, якщо він тільки збільшує розмір файлу? Не легше просто передати вихідний файл? А також, який сенс auth і jwt, добре, jwt я ще бачив відео про два ключі(доступу і оновлення) але по суті, всеодно знадобиться збереження цих даних в бд за ID, і відправка цього ID, на сторону клієнта, а потім ще паритися з відновленням і заміною цих jwt & IDFromDB, це я ще не кажу про доступ з декількох пристроїв, а також захисту серверу від DDos атак з перебором ID, а якщо ID використовується з якимось алгоритмом то взагалі пиши пропало. Із цього випливає, що JWT & auth додає тільки поля з даними і кодує під base64(чи що там).
Чи є реально захищені варіанти реалізації наприклад сесій і авторизації в додатку, окрім встановлення express-rate-limit?
Так, кодувати бінарні дані у вигляді тексту не завжди потрібно, але часто використовують, бо багато текстових протоколів. Наприклад JWT має підпис, який бінарний, а хедери в http1.1 розділені "
" й в бінарних даних може бути такий байт й відповідно буде битий запит. Але якщо його закодувати в base64, то проблеми немає. Те саме стосується й картинок в CSS (їх можна тягнути окремим файлом, але якщо це іконка, то й не треба робити запиту додаткового, наприклад). Часом basе64 корисний, коли треба в логі записати якісь бінарні дані, а логи це зазвичай текстові строки.
Відносно використання JWT, то основна користь в тому, що це не просто рандомний набір символоів, а якісь дані, яки приходять й яким можна довіряти, бо вони підписані. Також в JWT підпис можна робити приватним ключем, а перевіряти публічним. Тобто інші системи можуть перевірити, що запит прийшов від певного юзера, але їм достатньо мати для цього лише публічний ключ. Але так, сесії можна зробити просто по токену й без JWT, але проблема оновлення залишається. Звучить, як гарна тема для відео :)
Відносно захисту від перебору, то rate limiting може працювати (можна обмежувати кількість запитів з одного айпі, чи можна обмежувати перебори для одного акаунту та інші)
jabascript 🐸
Бачу позаду прям студія звукозапису?
Просто красивий фон)
я так і не зрозумів навіщо бінарні данні перетворювати на текстові данні.
В JWT, наприклад. Чи картинку в CSS, чи HTML вкласти, щоб не тягнути окремо. Basic auth використовує base64, щоб можна було передати логін й пароль. Часом треба якісь бінарні дані просто записати в лог-файл або покласти а конфіг. Багато текстових протоколів (той самий HTTP, атачменти в пошті, ключі шифрування для того самого ssh) й форматів існує й часом в них треба вкласти бінарні дані
так нащо він потрібен?)
Бінарні дані в текстовому вигляді зберігати/передавати
❤❤❤❤❤❤❤❤❤❤❤❤❤
Дякую, це прекрасно коли тебе цікавить тема і тут вона дуже добре розкрита 👍👍👍
Круто, зрозуміло пояснюєш, лайк, підписка, дзвіночок. Бажаю каналу розвитку і купу підписників.
дуже круто такий рівень пояснення мати українською😊
У мене була прогалина в цій темі. Те що треба, дякую!
Неочікувано досить круто :-)
Дякую велике за такі наглядні пояснення та відео вцілому)
такий контент хочеться дивитись и дивитись! щиро дякую👏
для tr можна просто перелічити символи *tr -d '
-'*
Яку ж ти годноту знімаєш, дякую)
Вогонь 🥁
Дуже дякую! Чудове подання матеріалу! Перевірте будь-ласка посилання на гітхаб (може щось з доступом)
Ох, забув запушити 🤦🏼♂️ Пофікшу, дякую 🙂
Коли побачив що user and password ми передаємо по мережі, вони є закодовані то був трішки шокований, і тут відразу питання що https нам дійсно дає секнюрність і ці дані не можуть бути перехвачені? І чому них не можна шифрувати?
Так, вся безпека веб будується на базі https. Чи можна перехопити дані при використанні https - так, але при певних умовах, при підміні сертифікату сервера. Щоб замінений сертифікат пройшов перевірку, він має бути підписаний приватним ключем центра сертифікації для якого на клієнті є публічний ключ.
Тобто, якщо вам хтось встановитить сертифікат (в якому публічний ключ) певного центру сертифікації на комп, то цей центр сертифікації зможе генерувати сертифікати для будь-якого сайту.
Така схема буває на корпоративних ноутах, щоб моніторити шифруванний трафік.
Відносно Basic Auth, то там ще є проблема з CSRF. Ну й ще є Digest Auth, який вже не передає пароль у відкритому вигляді, але теж має власні проблеми
https і дає рівень захисту шифруванням, це посуті надбудова над http
це більш універсальне рішення, ніж додавати шифрування для особливих складових http
перехват зашифрованих даних не дає доступ до цих даних, тому https і забезпечує безпеку