×Закрыть

Бесплатный курс по JS

Некоторое время назад я попросил вас написать какой бы бесплатный курс вы хотели, чтобы мы запустили в ProCode IT School первым, вы выбрали курс по JS и Node.js.

Стартует в субботу(11.04.2020) 19:00. Максимальная длительность 4 часа.

Курс стартует в виде стрима на нашем канале в YouTube, ссылка на стрим (нажми колокольчик чтобы не забыть).

Что будем учить?

За основу я взял наш стандартный курс FullStack FrontEnd, здорово сократив его конечно, все таки оригинальный курс это год обучения и более чем 500 часов практики. Чем-то пришлось пожертвовать, но помните что всегда можно написать в чате стрима вопрос или личное сообщение в телегу, я читаю и отвечаю на все ваши вопросы.
В программе у нас будет следующее:

  1. Основы JS
    Это начало курса, тут мы начнем с основ.
    Тезисы: асинхронность, переменные, типы данных, массивы, функции, объекты console.log, основы браузерного JS
    Требования: Базовые умения алгоритмизации. Если у вас в школе был хоть какой то язык программирования, хоть на минимальном уровне, basic. pascal или даже написания формул в exel, то все хорошо. Минимальные знания html\css.
    Софт: VS Code (VS Studio Code), плагины: Live Server, ESLint. Chrome
  2. Node.JS — Введение
    Это начало курса, тут мы начнем с объяснения зачем нужен Node.js, экскурс в историю зачем и для чего он был создан, где Node.js использовать точно не надо а где наоборот — лучше всех. Эта тема базовая, она дает вам лучшее понимание для чего вы все это учите.
    Тезисы: асинхронность, переменные, типы данных, console.log.
    Требования: Базовые умения JS из предыдущего блока.
    Софт: установленный Node.js последней версии
  3. Node.JS — Основы
    Блок разных знаний, которые нужны для того чтоб вобще начать работать с этим. Тут узнаете и про модульность в Node.js, и про ее специфические особенности, и про то как работать с конкретными наиболее важными модулями.
  4. Node.JS — Фреймворк Express
    Express это то без чего вы не можете просто нормально работать с Node.js. У Express есть аналоги, мы вкратце упомянем их для общего развития, но на сегодня Express это наиболее распространенное решение, обгоняет ближайшего конкурента, если быть точным, в 26 раз (в Node.js мы можем видеть реальную статистику скачиваний любой библиотеки)
    Тезисы: express, шаблонизация, роутинг, паттерны в express, валидация, ajax.
    Требования: Базовые умения JS из предыдущего блока.
    Софт: установленный Node.js последней версии
  5. Node.JS — Базы данных
    Мы будем изучать с вами MongoDB, эта самая удобная база данных для Node.js. Я очень рекомендую вам дополнительно изучить также и MySQL. Это очень востребованная тема и на основном платном курсе мы ее проходим. Она не имеет особого отношения к ноде, но среди работодателей это распространенный запрос.
    Тезисы: основные правила построения бд, типовые запросы, join в mongoDB (ref), модели, Mongoose.
    Требования: Соединять Mongodb мы будем с Node.js, вам нужно понимать что я пишу.
    Софт: установленный Node.js последней версии, MongoDB Community Server. Robo 3T(не Studio 3T)
  6. Авторизация
    Любой, даже самый примитивный сайт, пускай это маленький интернет магазин или огромный интернет портал, они зачастую имеют авторизацию. Потому среди множества практических тем из основного курса я оставил для вас именно эту. Мы детально рассмотрим наиболее современный способ авторизации — JWT и вкратце пройдемся по еще и сессиям, но вкратце. Сессии старый способ, но распространенный, вы точно столкнетесь с ним и на досуге я рекомендую вам углубиться в него дополнительно. В основном я буду говорить о JWT.
    Тезисы: session, cookies, jwt, авторизация.
    Требования: Авторизация требует работу с базой данных, на этом этапе вы должны уже уметь работать с Mongodb.
    Софт: Node.js последней версии, MongoDB, Robo 3T, базовое Express приложение с предыдущих занятий.

* порядок тезисов не совпадает с их хронологией.
** 1 темя не равно одному занятию. Это просто темы.

В конечном итоге, изучив бек и браузерный жс на базовом уровне, базу данных и авторизацию, вы сможете сделать сайт среднего уровня, примерно как интернет магазин розетка или небольшой сайт компании. Такие небольшие проекты как раз большая часть работ у среднего-малого работодателя. Крупные проекты встречаются гораздо реже. Знания этого курса уже позволят вам работать, но не лишним будут также знания React или аналога. Это знание переведет вас в категорию более квалифицированных специалистов, с другими перспективами, другими зарплатами и ценностью как специалиста. Курс по React будет позже, если конечно у нас все получиться с онлайн форматом.



Статистика ваших запросов

Всего 60 заявок, из них 81% это собирательный ключ по js. То есть, JS, Node.js, React, redux и прочее, но так или иначе требующее JS. Остальная часть это в основном Java и Python

Кто меняет профессию? много ли новичков?

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

Как назвать ребенка чтобы стал программистом?

По нашей статистике, среди тех кто учит сейчас программирование, много счастливых мам в декрете. Думаю эта информация будет весьма актуальна.

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



Мы продолжим выпускать бесплатные онлайн занятия по вашим заявкам. Форма заявки остается все та же. Также подписывайтесь на наш ютуб канал где будет идти стрим занятия и на нашем сайте вскоре появиться раздел с расписанием бесплатных занятий. Мой телеграмм @TrustyWork, вы всегда можете написать туда и задать вопрос по программированию. Ну или сайт заказать, это тоже туда =)

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Вот еще а голову пришло, можете рассказать про querybuilder?

Не работал, боюсь на этот счет ничего.

А кто работал с БД Vertica DB из node.js? Такое возможно?

Хлопцы, а кто может объяснить, почему в node.js вебсокеты будут ненужны, при условии передачи в сессию специального идентификатора? Можно добавить тему взаимодействия воркеров в node.js.

Да, тема по моему интересная, пишите об этом в заявке, в порядке очереди расскажу про все.

Как назвать ребенка чтобы стал программистом?
По нашей статистике, среди тех кто учит сейчас программирование, много счастливых мам в декрете. Думаю эта информация будет весьма актуальна.

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

это полный п****ц... писать на компьютере научили а думать — нет

он же курсы организовывает — может он это в серьез

он это в серьез

И да, и нет. Статистика реальна но выборка очень маленькая. Позже, когда буду делать после карантинный обзор рынка, соберу полную статистику и добавлю туда и имена возможно. Добавлено конечно это для смеха, но все зависит от того насколько вы верите в такие вещи. Потому и цифры реальные.

Мы детально рассмотрим наиболее современный способ авторизации — JWT и вкратце пройдемся по еще и сессиям, но вкратце. Сессии старый способ

Пропал калабуховский дом...

ДЖВТ — модно
Сессия — не модно

сессия плохо по многим другим причинам.

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

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

Состояние в коде всегда будет — вопрос откуда его читаешь ничего не меняет для кода.

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

Но нет, эти все кто пишут РСУБД, кафки, бигтейблы, JMM — мудаки, а один анонимус знает что надо засрать всю программу стейтом и хаотично его мутировать из рандомных потоков, чтобы лучше работало. За то вэлью!

Понятно, ну может хоть кризис поможет

Если кратко, то вот такой пример, имеем распределенную систему, неважно каким образом распределенную, важно что распределенную. Распределили ее не просто так, а по делу и постарались сделать минимум дублирования кода. Это введение.

А теперь в эту систему вы вводите общий элемент — коллекцию сессий в бд, и как минимум у нас общие модели возникают, что явно не то что нам нужно + любой муда человек, если не заморачиваться с правами доступа, может эти сессии бесконтрольно менять и полностью закрывает данные сессии от логики на фронте, что тоже менее удобное если у вас там frontend с блекджеком и реактом, а не просто верстка с jQuery. Есть много нераскрытых моментов в таком объяснении конечно, но то и урок я буду проводить чтобы рассказать подробнее. То где JWT не проявляет своих преимуществ — это монолитные приложения с примитивным фронтом.

да.... спросонья написал особо грамотно, надеюсь разберетесь.

ох, ладно, начну с конца

Frontend:

JWT — просто токен, который frontend обычно обновляет, но это не обязательно

Session — просто токен, который обычно обновляет backend, но это тоже не обязательно

С точки зрения frontend это character sequence с которым можно сделать только одно — отправить на сервер, ну или же получить новый и начать его использовать.

В 99% случаев для frontend, JWT усложняет flow и вводит дополнительный риски, но не дает никаких плюшек.

В 99% случаев для frontend, session является относительно прозрачным механизмом, то есть более легок в реализации.

Вывод — с точки зрения frontend нету никакой разницы между первым и вторым.

------

Backend:

JWT — обычно создается 1 раз с определенным содержанием, является неизменяемым, если надо менять прийдется создать новый токен.

Session — обычно создается 1 раз и является ссылкой на объект в каком-то хранилище данных или же объект в памяти сервиса. Однако, менять или не менять остается на усмотрения разработчика, можно сделать ее immutable путем создания определенной абстракции (SessionManager с 3 методами createSession(sessionContent); deleteSessionById(sessionId); getSessionById(sessionId) — то что вернет createSession и getSessionById является immutable объектом). Backend может управлять в той мере, в которой ей необходимо, но берет на себя ответственность за это.

Как мы видим, JWT это всегда immutable и не требует внешнего хранилища данных.

Session может быть mutable или immutable, и может требовать внешнее хранилище данных (если оно отсутствует тогда появляются проблемы для распределенных систем).

Вывод — с точки зрения backend, разница есть и довольно большая, плюс безопасность не была затронута, но обычно у session с ней всегда лучше.

-------

Распределенные системы и дублирование кода

Можно создать shared library с которой вы будете пользоваться в своих сервисах и поможет избежать дублирование кода, однако накладывает ограничения, что сервисы в вашей системе должны быть на одном языке. Если нужны в разных технологиях прийдется создать несколько shared library. JWT помог бы этого избежать так как это стандарт, и скорее всего уже есть существующая библиотека в вашей технологии которая работает таким же образом. Однако, даже в случаях sessions это не настолько велика проблема.

Даже в распределенных системах можно реализовать эффективную мутацию данных в session, путем создания для каждого сервиса который бы в этом нуждался отдельных коллекций/или же отдельных под объектов . Это было бы наиболее эффективно для реализации в релятивной БД, либо немного менее эффективно в документной которая обеспечивает lock, на уровне документа.

-------

Главный вывод — пожалуйста перестаньте смешивать наиболее популярное решение с чистым решением. Всегда есть возможность менять некоторые элементы вокруг решения, при этом само решение останется прежнем.

-------

Если есть еще вопросы, сомнения — то лучше созвонимся, а то еще целую статью мне катать не хочется.

Не соглашусь. Возможно мы с вами используем разные паттерны по разному и другие приемы разработки. Для меня JWT значительно все упрощает, а возможностей сессий чисто для авторизации уже не хватает. При этом я могу их комбинировать на проекте и не смотрю на сессии как на что-то не приемлемое вообще.

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

Для меня JWT значительно все упрощает

объективно проще то что требует меньше манипуляций, все остальное субъективно и основано на личных привычках и опыте.

возможностей сессий чисто для авторизации уже не хватает

и вот это странно ввиду того, что как раз сессии дают больше возможностей.

При этом я могу их комбинировать на проекте

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

объективно проще то что требует меньше манипуляций

Совершенно верно. Можно делать общие либы и прочее, но зачем это делать, если можно не делать. Объективно JWT требует меньше усилий для реализации.

и вот это странно ввиду того, что как раз сессии дают больше возможностей.

о каких конкретно возможностях идет речь? Я вижу только возможности серверного стора, но в нем нет какой то необходимости, если речь идет об авторизации..

а этого лучше не делать.

Это можно делать, нет никакого зоопарка технологий. Сессии это сессии, а JWT это всего лишь вариация надежного токена. Вам стоит попробовать поработать с JWT. Раньше вы использовали в качестве токена — айди сессии, что с свою очередь тянуло привязанный к этому айди стор, если мы говорим о ноде, то такой стор хранился в бд. Теперь, вы получили такой же токен, но он одновременно является и стором, вот вся премудрость JWT. Запишите JWT в кукес, установите флаг HTTP Only, и вот ваша сессия, только реализованная на JWT(а так можно было??! Да, можно).

Объективно JWT требует меньше усилий для реализации.

столько же, если у вас готовая библиотека со стороны сервера для сессий, а скорее всего она есть, поэтому

Объективно JWT требует меньше усилий для реализации.

не принципиально, если манипуляции спрятаны за абстракцией

о каких конкретно возможностях идет речь?

я привел выше в развернутом ответе.

Вам стоит попробовать поработать с JWT

я с JWT работал более чем достаточно и в монолитах и микросервисах. как и с сессиями в монолитах и микросервисах

Запишите JWT в кукес, установите флаг HTTP Only, и вот ваша сессия, только реализованная на JWT.

это не сделает из JWT сессию, а просто вы меняете способ передачи информации

Окей. Давайте разберемся с тем что вы писали выше.
JWT это токен, но сессия это не токен, это механизм использующий в какой-то своей части токен, в том числе можно реализовать сессию используя и JWT. Вы согласны с этим?

Да, правда использовать jwt token как идентификатор сессии весьма странное решение

Зато стильно, модно, молодежно же...

ну если бы у меня кто такое в проекте сделал бы, код ревью никогда бы не прошел

По моему вы предвзятые. Оба.

нет. хранить данные в токене который ссылается на те же данные + какие-то еще — это то что называется говнокодом

перефразируйте, не понял о чем вы.

насчет монолита не согласен, любое серьезное приложения — это монолит...

Подразумевается монолитный тип архитектуры, как альтернатива это могут быть например микросервисы или другие варианты.

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

под капотом твоего уютного скала мирка

знаю что под капотом у моего уютного скала мирка, не прибил. Главное что оно достаточно надёжно под ним спрятано и не прорывается

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

сколько не нужных букв...

JWT — stateless
Session — stateful

Нет, потому что $_SESSION. Просто для джава скриптеров это не так существенно.

wat?

jwt — не требует хранилища данных по стороне сервера — stateless
сессии — требуют хранилища данных по стороне сервера — stateful

Да вы правы, с другим термином перепутал. Но тем не менее, это были нужные буквы.

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

Слушайте, это же инженерный вопрос, а не религиозный, зачем весь этот маркетинговый буллшит?

Уже только «такого момента как логаут» самого по себе достаточно, чтобы десять раз подумать стоит ли использовать JWT. Ваш юзер подозревает, что его пароль скомпроментирован, заходит в аккаунт, меняет пароль и ... в общем-то идет на йух — потому что токен, которым распогалает злоумышленник, остается валидным и нет никакой возможности его отозвать. Точнее, есть одна — поменяв серверный ключ, и тем самым убив вообще все токены всех остальных клиентов разом. Божественное юзабилити и офигенное «современное решение», ага.

У JWT есть ровно одна фишка — statelesss, — которая оправдывает его применение в некоторых сценариях (айдентити сервис раздающий короткоживущие токены, с которыми клиент может делать запросы к другим сервисам и т.п.). И даже тогда нужно понимать ограничения и риски (проблема-то отсутствия контроля никуда не исчезает, так что токены должны быть короткоживущими и/или одноразовыми, например).

Если бы вы с вашими студиозусами нормально разобрали сессии (написали аутентификацию руками с нуля, без использования готовых либ) + поковыряли какой-нить Oauth2 (хотя-бы в объеме «взять готовую либу и прикрутить», хотя без написания хотя-бы части кода руками новичкам бывает сложно понять куда и какие запросы там ходят под капотом) пользы для неофитов было бы в 100500 раз больше.

есть варианты решить проблему логаута, но тут верно подмечено — инженерный вопрос, что вам нужно.

есть варианты решить проблему логаута

Например?

Если кратко, в зависимости от ситуации есть три основных(и несколько неосновных) приемов, которые можно комбинировать:

— коротко живущие токены
— убийство токена через фронт
— черные списки токенов

— коротко живущие токены

...означают жуткое юзабилити для юзеров. Это железке пофиг (утрирую) если на каждый запрос нужно рефрешить токен, а пользователя, которому нужно логиниться раз в 5 минут, вы очень быстро потеряете.

— убийство токена через фронт

Ну это со своими, а со скомпроментированными токенами (как вариант — моими же сессиями на других клиентах) что делать предлагаете?

— черные списки токенов

Ага, то есть состояние сессии мы убрали в типа стейтлесс токены, но теперь на сервере мы дегаем базу чтобы проверить состояние самих токенов. Отличный план (нет).

Коротко живущие токены это не значит что пользователю надо делать заново логин. Скомпрометированный токен и логаут это разные вещи, но допустим вы опасаетесь этого и по какой-то причине нам не подходят черные списки. Тут подойдут все те же решения, что используются для предотвращения кражи айдишников сессий.

Коротко живущие токены это не значит что пользователю надо делать заново логин

Это как? Допустим, юзер открывает приложение, логинится, фронтенд получает от сервера короткоживущий токен. Через условные 5 минут токен экспайрится. Опишите пжл что происходит при следущем запросе к серверу?

Скомпрометированный токен и логаут это разные вещи

Спасибо, кэп, не знаю что бы я делал без этого откровения.

допустим вы опасаетесь этого [компроментации — К.С.]

Ну конечно же я этого опасаюсь. Единственный смысл аутентификации — это предотвращение несанкционированного доступа к ресурсам, так что любые дыры — это таки да, проблема, просто по определению.

по какой-то причине нам не подходят черные списки

Вы же прекрасно поняли суть возражения. Зачем отказываться от серверных сессий в пользу стейтлесс токенов, если при этом нам нужно будет иметь серверный же блеклист? Мы же при этом получаем все недостатки JWT (больший вес, больший оверхед процессинга, ...) убив при этом их по сути единственное преимущество — иммутабельное состояние...

Тут подойдут все те же решения, что используются для предотвращения кражи айдишников сессий.

Продолжаете жечь напалмом. Разговор начался с того, что мы уже подозреваем компроментацию сессии, и нам нужно защитить свои данные. При чем здесь «предотвращение»? Всё, проехали этот этап, мы попытались предотвратить но что-то пошло не так.

Это как? Допустим, юзер открывает приложение, логинится, фронтенд получает от сервера короткоживущий токен. Через условные 5 минут токен экспайрится. Опишите пжл что происходит при следущем запросе к серверу?

Для таких сценариев используются refresh токены. Они как правило долгоживущие в отличие от access токенов.

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

Покажи мне хотя-бы одну статью, которая аргументированно объясняет почему сессии в JWT — это хорошо. Потому что я на 146% уверен в обратном.

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

В RFC, описывающим реализацию JWT написано, как с его помощью реализовать надежную аутентификацию? Это что-то новенькое. Дайте ссылочку на конкретный раздел, пжл.

Этот ментор слился. Можно следующего посмотреть?

увы, вы правы, мне не это морально уже не под силу.

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

Вот смотри, у нас есть бек и два клиента — вебморда и телефон. Человек и там, и там залогинен. Телефон украли. В случае серверной сессии все просто как грабли: человек логинится в вебморду (если успел :)), меняет пароль — старая сессия умерла, мобильный клиент превратился в тыкву (в реале все не так шоколадно, но не будем усложнять пока). Теперь я очень — ОЧЕНЬ! — хочу послушать, что предлагает делать Александр в случае, если у него сессия лежит в токене. Пока вижу только попытки увильнуть от ответа.

Для начала дисклеймер: я далек от холивара сессии версус токены по причине того, что оба этих понятия существуют в той или иной форме в авторизационных механизмах (в токен-based механизмах сессия все равно есть, но находится на сервере авторизации, а не на сервере ресурсов, а сессионных механизмах есть идентификаторы сессий которые в некотором роде играю роль токенов), а разница лишь только в декомпозиции оветсвенностей — в токен-based модели отвественность за поддержание сессии убирается из ресурсного сервера, что имеет как преимущества так и недостатки. Именно поэтому инженерный подход не приемлет подхода плохо/хорошо, а применимомсть той или иной модели зависит от условий задачи.
Теперь конкретно по сценарию в модели с токенами. Клиенты сохраняют долгоживущие refresh токены которые не используются для взаимодействия с сервером ресурсов а только с сервером авторизации. Злоумешленник укравший мобильное устройство все еще может использовать access token для взаимодействия с сервером ресурсов, пока его короткое время жизгни не истекло, а также может использовать refresh token для получения новых access токенов до тех пор пока мы его явно не отозвали на авторизационном сервере, что очевидно может быть доступно как смена пароля или как дополнительная функция для пользователя. Т.е. по сути сценарий в плане уязвимисти мало отличается от сессионного е единственное чувствительное место это время жизни access токена, которе можно при желании сделать очень коротким увеличив кол-во запросов к серверу авторизации и таким образом пожертвовав другими quality атрибутами.

в токен-based механизмах сессия все равно есть, но находится на сервере авторизаци

Это ключевой вопрос, дальше можно ничего не говорить — я в курсе того, как это работает. Ну разумеется, наличие сервиса авторизации, хранящего стейт сессии, решает проблему. Но суть-то текущего, как ты говоришь, холивара именно в том, что Александр в принципе отрицает сессии :) Они у него «устаревший механизм», в противовес стильным модным молодежным стейтлесс токенам. Задавая свои вопросы я просто хотел его вывести на тот простой вывод, что сессии а) все равно так или иначе нужны и б) нет никакой возможности держать их на фронте и не пробить дыру в безопасности системы. Всё.

Ну разумеется, наличие сервиса авторизации, хранящего стейт сессии, решает проблему

Это обязательный компонент для token-based моделей, таких как например OAuth.

Нет Констатнтин, вы просто невнимательно читаете. А также заблуждаетесь что JWT создают дыру в безопасности. Похоже вы просто не понимаете как работает JWT. Я сказал что сессии это сессии, и что сессии это не только авторизация, а еще говорил что сессии не равны токену, и говорил что для типового монолитного приложения, JWT не проявляет явных преимуществ. А вы с Антоном Коваленком (ака anonymus ps), просто восхваляете сессии и принижаете преимущества JWT.

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

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

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

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

Не начинайте еще один холивар, почитайте зачем были созданы реляционные базы, потом пишите мне в телегу и там обсудим сколько вам душе угодно. Но только после того как прочитаете зачем были созданы реляционные бд.
А про JWT и сессии это про разное — вот все что я хочу сейчас сказать.

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

Так я же не против что сессия и джвт это разное, я как раз таки очень даже за. Вспомни пожалуйста об этом на своих лекциях да и все, только в нормальном ключе

Я сказал что сессии это сессии, и что сессии это не только авторизация, а еще говорил что сессии не равны токену, и говорил что для типового монолитного приложения, JWT не проявляет явных преимуществ.

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

Мы детально рассмотрим наиболее современный способ авторизации — JWT и вкратце пройдемся по еще и сессиям, но вкратце. Сессии старый способ

Итак, для любого человека, для которого русский язык является родным, эта фраза несет совершенно однозначную семантику: «сессии и JWT взаимозаменяемы, токены лучше, потому что новее». Можете проконсультироваться у профи лингвистов, если мне не верите. Вы не это имели в виду? Так сказали бы сразу, чё три короба ерунды всякой городить.

Вы не сможете реализовать надежный механизм аутентификации используя только JWT. В принципе не сможете. Да, JWT могут быть хорошим механизмом межсервисной аутентификации, но при этом все равно где-то есть сервис, где все ниточки сходятся в сессию в том или ином виде. Обойтись без JWT можно, обойтись без сессии — нет (если уверены в обратном и можете привести пример реализаци — буду очень признателен).

А теперь у меня вопрос: так почему тогда вы в своем курсе обходите вниманием необходимые основы, а вместо этого концентрируетесь на опциональном инструменте, без которого можно обойтись? Вы понимаете, что неофит, которые не понимает нюансов надежной аутентификации, но умеющий совать состояние сесии в «неуправляемый» токен — это по сути обезьяна с гранатой?

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

А как JWT работает хоть описать можете?

Процитируй, что-то не пойму о чем ты. Александр предлагает абсолютно типовые решения, не им придуманные.

Таймкоды, пожалуйста, запилите

Хлопцы, молодцы, с удовольствием посмотрю если получится...Очень бы хотелось услышать про ML, Blockcain. А также про работу с сетевыми протоколами, это вообще мало где найдешь

Боюсь не влезет в такой маленький курс. По протоколам, я пройдусь конечно по верхам, но очень верхам.

Очень жаль, можно хотя бы вкратце про смарт контракты или хотя бы про этот зоопарк ->www.youtube.com/watch?v=b1e3oBnupe8

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

А можно тогда рассказать в чем прелести разработки смарт контрактов на node.js, почему на них в основном разрабатывают подобные проекты?Еще две интересных темы node.js и udp протокол, REST API скоро отомрут?HTTP3 и node.js уже реализована поддержка на node.js?node.js и Rust про токио можно будет рассказать?Typoscript и node.js расскажите?

REST API скоро отомрут

Сначала почернеют и засохнут.

Хлопцы аргументирую=>
Типичные современные службы RESTful фактически реализуются с использованием HTTP или HTTPS через соединения TCP / IP. Невозможно напрямую общаться с TCP-сервисом, использующим UDP. Пакеты уровня IP будут иметь неправильное семейство протоколов, и операционная система службы не будет направлять их в службу.
Фактически, возможно (технически говоря) реализовать службы RESTful на любом транспорте, который способен отправлять сообщения. Принципы REST не зависят от транспортного протокола. Проблема заключается в поиске сервисной инфраструктуры, которая будет поддерживать это, а также обычного RESTful HTTP.
Есть еще пара других практических проблем:
UDP ненадежен, и это усугубляется, если вы отправляете дейтаграммы, которые не помещаются в пакет с MTU по умолчанию (1500 байт).
HTTPS использует TLS, чтобы клиент проверял подлинность сервера и затем отправлял данные в зашифрованном виде. TLS поверх UDP возможен (он называется DTLS) и поддерживается JCSE, но использование его в типичной среде RESTful / HTTP может быть проблематичным.
Будет ли в скором времени существовать среда RESTful, которая реализует CoAP (протокол — RFC 7252) и DTLS?

с TCP-сервисом, использующим UDP.

Начиная с этого места я перестал улавливать ход мысли.

TCP буфер надо правильно настроить(как правило это сложно), поймать баланс, чтобы не упираться в сеть и не раздувать буфер. Для собственного UDP-протокола все просто — этим можно
и нужно управлять! TCP- умер, да здравствует UDP!

TCP- умер, да здравствует UDP

Хм серъезная заявка, только боюсь без переизобретения своего TCP колеса о надежном транспорте и секьюрити лучше не вспоминать.

TCP буфер надо правильно настроить(как правило это сложно)

Что конкретно сложно?
Я вообще-то об этом оксюмороне:

TCP-сервисом, использующим UDP

Если вы еще не верите, что TCP умер, то я вам скажу такое, что когда вы ходите в интернет то используете Chrome, Android, а скоро и iOS, и даже если шагаете в google, youtube и прочее, то используете QUIC и UDP

Т.е. только на гугловские сервера? Остается только весь остальной трафик посчитать, а так ну да конечно умер.

TCP-сервисом, использующим UDPЯ имел ввиду не юзание TCP и UDP вместе — вместо этого лучше реализовать «фишки» TCP, которые вам необходимо использовать на конкретном проекте, самостоятельно, на основе UDP. Проблема заключается в том, что раз TCP и UDP оба работают поверх IP, пакеты обоих протоколов будут влиять друг на друга — уже на уровне IP. Как конкретно будет проявляться это влияние очень сложно предугадать, и это связано напрямую с механизмами обеспечения надежности в TCP. Но, в любом случае, использование TCP обычно приводит к увеличению потерь UDP пакетов web.archive.org/...​7/proceedings/F3/F3_1.HTM

Проблема не во взаимном влиянии, а в отсутсвии в UDP механизма flow control, из за чего он просто не в состоянии реагировать на измения пропускной способности приемника. Если ты сделаешь что-то поверх UDP со своим flow control это решит проблему только для этого конкретного чего-то, а остальной plain UDP траффик будет так же подвержен проблемам потерь.

В протоколе UDP отсутствует встроенный в протокол механизма flow control(контроля перегрузки), поэтому это лучше для сетевого стека, он просто отправляет дейтаграммы драйверу сетевого адаптера, который выдает их в сеть как можно быстрее. При использовании асинхронного API, такого как например API порта завершения ввода-вывода Windows, операция отправки асинхронной дейтаграммы не завершается до тех пор, пока драйвер NIC не завершит работу с дейтаграммой, после чего для завершения он будет поставлено в очередь на IOCP, и приложение сможет повторно использовать или освободить буфер памяти, содержащий данные датаграммы. В течение времени между выполнением операции отправки дейтаграммы и завершением получения требуются как выделенная приложением память, так и выделенный невыгружаемый пул операционной системы. Если приложение отправляет дейтаграммы быстрее, чем драйвер NIC может поместить их в сеть, то эти завершения приложения будут замедлены, и увеличится время, необходимое для использования как памяти, так и невыгружаемого пула.Разве это плохо?

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

HTTP является протоколом на основе TCP / IP. Поэтому, когда вы используете REST, вы уже используете TCP для связи. Но если вы хотите использовать REST поверх чистого TCP-сокета, без HTTP, то нельзя, это не имеет смысла, поскольку REST основан на HTTP. Эти понятия существуют только в протоколе HTTP.Через

UDP

нельзя разве в request постучаться?

поскольку REST основан на HTTP.

Откуда такой вывод?

Да, REST охватывает более широкую область, нежели HTTP — его можно применять и в других сетях с другими протоколами. REST описывает принципы взаимодействия клиента и сервера, основанные на понятиях «ресурса» и «глагола» (можно понимать их как подлежащее и сказуемое). В случае HTTP ресурс определяется своим URI, а глагол — это HTTP-метод.
Но! Есть небольшая проблема с применением REST на практике. Проблема эта называется HTML/2 т.к. PUT/DELETE запросы можно отправлять посредством XMLHttpRequest, посредством обращения к серверу «вручную» (скажем, через curl или даже через telnet), но нельзя сделать HTML-форму, отправляющую полноценный PUT/DELETE-запрос. Поэтому...

Нету в REST никаких глаголов. Есть control data, которая может содержать тип оперции совершаемой над ресурсом. Так исторически случилось что в REST HTTP имплементациях для этого используют HTTP verb, но REST не устанавливает никаких ограничений на это счет. В чем проблема так и не понял.

Спецификация HTML не позволяет создавать формы, отправляющие данные иначе, чем через GET или POST. Поэтому для нормальной работы с другими методами приходится имитировать их искусственно.

REST поверх чистого TCP-сокета
это не имеет смысла

Потому что REST как архитектурный стиль предусматривает определенные constraints которые ограничивают то как и где его можна применять. Советую ознакомиться: www.ics.uci.edu/...​ation/rest_arch_style.htm

Но если вы хотите использовать REST поверх чистого TCP-сокета, без HTTP, то нельзя, это не имеет смысла, поскольку REST основан на HTTP. Эти понятия существуют только в протоколе HTTP

Representational state transfer (REST) is a software architectural style that defines a set of constraints to be used for creating Web services.
en.wikipedia.org/...​entational_state_transfer

REST взял примером HTTP, но это не значит, что он реализуем только поверх HTTP.

Уже существует...HTTP/3 — это просто новый синтаксис HTTP, который работает на IETF QUIC, мультиплексированном и безопасном транспорте на основе UDP.

В протоколе UDP отсутствует встроенный в протокол механизма flow control(контроля перегрузки), поэтому это лучше для сетевого стека

Наличие или отсутсвие flow control не влияет на сетевой стек отправителя. Его задача не перегрузить получателя, потому что в противном случае он начнет отбрасывать пакеты.

Если приложение отправляет дейтаграммы быстрее, чем драйвер NIC может поместить их в сеть, то эти завершения приложения будут замедлены, и увеличится время, необходимое для использования как памяти, так и невыгружаемого пула.Разве это плохо?

Маловероятный сценарий в сетевых приложениях, но тем не менее если такое происходит ничего хорошего в том что у тебя увеличивается non-paged pool, application memory и очередь I/O запросов нету.

Фактически, возможно (технически говоря) реализовать службы RESTful на любом транспорте, который способен отправлять сообщения.

Да, совершенно здравая мысль, но речь идет об application, а не транспортном протоколе поскольку REST имеет весьма четкий constraint Client-Server, который предусматривает наличие request/response взаимодействия.

Можно глянуть в сторону SIP. Там такое реализуется поверх UDP.

Конечно, и я о том же, что голый транспорт TCP/UDP не подойдет, нужно еще что-то сверху.

можно написать свой UDP протокол, если вы уверены, что у вас очень специфичная задача и конкретные пользователи.Например,проект-блокчейн-логистика...

можно написать свой UDP

Нельзя — UDP протокол уже есть, а свой это уже будет не UDP, а какой-то другой, но какой смысл писать свой транспортный протокол я никак не могу понять.

можно написать свой UDP протокол

Ваш маиндсэт идеально подходит под разарботку на js и особенно на фронтэнд :-)

www.youtube.com/...​0bL2Zp1c&feature=emb_logo
тут очень много всего, в том числе ответ на ваш вопрос.

У меня вообще-то вопроса не было.

Да нет по факту никакого RESTful, в том виде как он должен быть академически. Потому и не умрет, его существование было еще до REST. Позже эту концепцию описали и дали названия, после чего она стала доступна тем людям которые делали по другому. Они оценили и начали использовать, но снова таки, не в чистом академическом виде.

Форма заявки по прежнему доступна. Я расскажу про любую тему, но в порядке очереди.

Потому что на ноде есть готовые пакеты с нпм и для ноды, нпм что-то родное и базовое, принципы разработки на ноде подразумевают большие возможности. Это если не лезть частности, тут отдельно можно прочитать лекцию где нода нужна, где нет и про особенности пакетов на ноде.

Про UDP не будет, а HTTP3, нода позволяет низкоуровневый доступ, можно придумать даже собственный протокол и заставить ноду с ним работать. Вопрос времени.

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

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

Я не работаю с растом просто, и у нас в компании никто не работает, по крайней мере я не слышал о таких. Блокчейны расскажу если будут заявки, но в порядке очереди.

Подписаться на комментарии