Александр Мельник

а вот еще хотелось бы мне подискутировать на затронутую мной же тему jwt токенов.
Кто скажет, почему payload не шифруется а лишь кодируется? В чем сокральный смысл использовать base64, который очень просто раскодировать и узнать данные?
Как я понимаю жизненный цикл access токена:
— сервер авторизации и сервер, на котором мы хотим обратиться знают один и тот же ключ, при помощи которого создана сигнатура в токене.
— мы при каждом запросе мы передаем этот токен на сервер. Сервер (в каком то midleware ну или как там разработчик сделает) берет payload и кодирует тем же ключем. И сравнивает сигнатуру которую он получил с той, что пришла в токене.
— если сигнатуры совпали это говорит о том, что запрос пришел от того, кто обращался на наш сервис авторизации и смог получить токен.
— НО мы ничего еще не знаем о самом клиенте. Кто именно делает запрос. А если у нас есть деление на какие то роли и не каждый кто просто получил токен имеет пользоваться всем. Или же мы ведем логирование запросов и нам нужен хотя бы id пользователя. Тоесть как ни крути, там же на этапе аутентификации нужно раскодировать payload и получить исходные данные, чтобы получить например объект с перечислением ролей и определить, допустима ли тому, кто отправил запрос, операция удаления пользователей.
— тоесть сам факт проверки сигнатуры не дает еще полной картины, раскодировать payload прийдется каждый раз.
— и в такой схеме действительно возникает проблема. Если токен украли, то пока он «жив» вор может пользоваться им и нанести вред.

Теперь собственно моя идея.
— раз нам все равно на каждый запрос нужно раскодировать payload токена, то почему не включить в него информацию, которая позволит решить проблему с угоном токена. Что-то что будет служить дополнительной защитой.
— к примеру ip адрес того, кто обратился на сервер авторизации и получил токен. Добавим ip в payload и на этапе аутентификации на своем сервере, сравниваем, а тот ip что пришел в токене и реальный ip который мы получаем из самого запроса — совпадают ли?
— так же в случае если мы говорим про применение jwt не для общения с api, а для использования в браузере, в токен можно добавить user-agent, который даст информацию о том, с какой операционной системы и с какого браузера был получен токен. И есть еще масса уникальной информации, которую можно получить и использовать для идентификации того или иного устройства.
— что это нам дает. Решение классической проблемы — угнали токен и до конца его жизни могут пользоваться. Теперь даже в случае угона токена, он не будет принят на сервере, на который мы стучимся, потому что точно не пройдет проверку ip и скорее всего не пройдет проверку user-agent.
— нельзя конечно полностью утверждать, что это 100 процентная защита от угона токена, вернее от возможности его использование вором, но это уже сильно усложнит жизнь вору. Насколько я знаю, подделать ip с которого отправляешь свой запрос на какой то конкретный (а чтобы токен прошел валидацию нужен именно конкретный), не так уж и просто. Но предположим что супер хакеры умеют.
— и мы возвращаемся к моему вопросу — почему payload просто кодируют, а не шифруют? Тот кто украл токен имеет прямой доступ к информации, пусть даже и не знает ключа шифрования, при помощи которого была создана сигнатура. В моей схеме, вор получив токен сразу же использует его чтобы получить доступ к нашему сервису. Не выходит, банально потому что его ip не совпадает с тем с которого он совершает запрос.
— если payload только закодирован base64 вор получает с него данные и видит, что в данных содержится и ip. И начинает как то решать эту проблему и искать способ подделать свой ip на этот конкретный. Если время жизни токена невелико то и времени для поиска решения не много. Но ведь можно не дать ему и этого шанса. Не будем кодировать, будем шифровать payload. Мы уже используем один ключ, который создает сигнатуру. Можем использовать его или завести еще один. Чистые данные шифруем при помощи ключа. получаем payload. payload шифруем при помощи ключа — получаем сигнатуру. Складываем их вместе, получаем довольно безопасный токен.
— теперь даже если украсть токен, то «тупое» его использование ничего не даст и дело не во времени его жизни, а в несовпадении данных из токена с реальными данными запроса. И посмотреть что лежит в payload хакер тоже не может, данные не закодированы, а зашифрованы и не имея ключа их не расшифровать.

Такой подход, как мне кажется, даже позволит завести в свой системе авторизации пару приятных плюшек:
— автопродление токена. Поскольку у нас теперь токен содержит дополнительные уровни защиты, то в зависимости от уровня безопасности всего проекта, можно облегчить жизнь нашим пользователем. Если токен пришел на сервер и в нем все идеально, кроме времени жизни (он уже протух), можно не отправлять пользователя на повторную авторизацию руками, а самим сделать запрос на наш сервис авторизации, передать туда данные из payload и получить новый токен. Никто ведь из людей не любит очень часто вводить пароль. Но это для проектов, чей уровень безопасности не высок.
— можно вести статистику успешных и неуспешных использований токена и на основании ее изменять время жизни токена для конкретного пользователя. Если видим, что присылается токен с зашитым внутрь одним ip а запрос приходит с другого ip, то в следующий раз этому клиенты выдадим токен не на 30 минут, а на 5 минут.

спасибо, я понял.

nginx у нас это прокси сервер, nitro это веб сервер. Причем я почитал документацию, он умеет отдавать и статику тоже.
Зачем использовать nginx, почему не настроить nitro на 80 порт и слушать запросы напрямую на нем?

А Nuxt и прочее Node.js это уже для серьёзных специалистов.

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

const site = new Site();
site->getWonderfullShop('no cart please');

Поэтому не соглашусь, что nodejs это для специалистов. Синтаксис там простой, библиотек море.
Вот ассемблер — это для специалистов.

с этим почти согласен. Ну разве что php-fpm не является серверов, это процесс демон интерпретатора php.

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

я не подскажу, к сожалению. Плохо вообще понимаю что такое nuxt и зачем это существует. Очень слабо понимаю, зачем для работы js фрейворков требуется аж два одновременно работающих вебсервера — свой и nginx (пусть даже последний выполняет роль прокси сервера). Это все равно если бы мы писали программу на php, переносили ее на продакшен, так запускали локальный веб сервер php
php -S localhost:8080 -t public
естественно что так до нашей программы нельзя достучаться из браузера, поэтому мы запускаем еще и nginx который настраиваем на проксирование всех запросов с порта 80 на порт 8080 и оно даже будет работать, но вопрос — зачем.
Но вам чтобы увидеть приветственную страницу именно так и нужно сделать. Установить nginx, настроить его дефолтный конфигурационный файл на слушанье 80 порта и тупое проксирование всех запросов на тот порт, на котором запустился ваш nuxt

да, текстом сложновато воспринимать такую информацию. за видео — заранее спасибо.

Круто, но мне кажется, это понятно пока только для вас)
Я вот прочел и не понял, как например менеджер может задать на определенной странице свой уникальный набор блоков и что самое важно — наполнить эти поля данными.
Я просто недавно тоже «изобретал» конструктор блоков на migx, потому что на некоторых сайтах возникает задача — хотим вывести на этой странице вверху блок — наши преимущества и указать один набор преимуществ. А на другой странице внизу вывести этот же блок, на заполненный другими данными. а на третьей странице вообще отключить данный блок.

значит не то смотрю.
Но в любом случае спасибо, потому что вы ответили на довольно важный в понимании работы nodejs вопрос. Можно я вкратце опишу, а вы скажите прав ли я в различиях в работе програмного обеспечения на php и nodejs
— nodejs в отличии от php не умеет работать в качестве модуля веб сервера или отдельного демона в системе, которому можно передать файл с кодом и он его выполнит. Как это мы делаем в php-fpm например. передаем код на некоторый сокет на котором работает интерпретатор php
— поэтому у нас в php и нет промежуточного понятия — сервер php. Ну формально он есть через команду php -S но он если и используется то только для разработки. Но nodejs может обрабатывать код только при наличии внутреннего сервера, вот почему и возникают exspress и им подобные?
— любое приложение на ноде (устал переключать раскладку) которое хочет работать с http запросам, должно запустить свой собственный сервер, настроенный на какой то порт, а запросы от клиента ему будет пересылать nginx слушающий 80 порт? Отбросить из этой цепочки внутренний сервер мы не можем? Как делаем в php? Когда у нас nginx просто перенаправляет все запросы в единую точку входа?

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

ну тоесть nginx все таки используется на продакшене?
Нет, не вопрос в том чтобы это запустить, я довольно хорошо разбираюсь в администрировании линукс серверов и смогу настроить и многодоменность и проксирование запросов.
Вопрос в том что это нигде не обсуждается разрабочтками ну и плюс наверное путаницей в терминологии. Вот Василий выше написал что nuxtjs разработал свой сервер, взамен express.
И у меня складывается впечатление, что именно на вот таких серверах (express, nitro) и работает все на продакшене без использования nginx, что кажется мне совершенно неверным решением.

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

плюс расскажите пожалуйста как вы решаете проблему «первого запроса».
Ведь токен нужно передать на сервер при первом запросе.
— пользователь запускает браузер
— вводит адрес
— браузер получает ip сервера
— в браузере в локалстораже лежит access токен
Каким образом он будет передан в первом запросе, чтобы пользователь сразу был авторизован?
Как этот вопрос решаете вы?

спасибо, я конечно же смотрел видео Ильи.
И он как раз тоже рассказывает о том, что jwt это небезопасный инструмент, тот случай когда технология стала популярной не за заслуги, а вопреки недостаткам.
Но мои знания теоретические, я еще нигде не использовал jwt в серьезных проектах.
По крайней мере украть куку через js гораздо сложнее (есть способы сделать ее недоступной) а вот доступ к
localstorage закрыть нельзя.

спасибо.

Но в инете много информации по этому вопросу. Странно задавать его здесь.

Но мы ведь с вами как раз и в инете) На сайте который представляет из себя форум, на котором обсуждаются технологии веб разработки и на котором находятся много умных людей, поэтому задать вопрос здесь — мне кажется очень разумным.
Я вот например впервые в жизни слышу про OpenID Connect. И ничего подобного по запросу — межсерверная авторизация мне не попадалось, а вы раз — и подсказали.
Вы правы, я жутко люблю изобретать велосипеды, а не использовать чьи то готовые решения. Понимаю, что в 2022 году это неправильный подход, но ничего поделать не могу. Для меня программирование это прежде всего изобретательство и наслаждение от поиска решения, а когда — установи вот эту библиотеку и скопипасти со стековерфлов такой то код — то это наоборот боль. Но это мои тараканы)

nextjs, nestjs,nuxtjs, vuejs — голова кругом идет. Причем я так понимаю что vue это фреймворк языка js, а nuxtjs это уже фреймворк фреймворка vue.
я часто вижу видео по разработки чего либо на nodejs, всегда все разработчики запускают какой либо из веб серверов у себя локально, на каком то доступном порту и разрабатывают. Но я никогда не видел, как это деплоится на продакшен сервер и самое главное, как это там работает?
Поделитесь пожалуйста информацией.
— вы что, на продакшене тоже не используете nginx? Кто именно слушает 80 порт и передает запросы приложению?
— как вообще решается вопрос с размещением нескольких сайтов на одном сервере? Если у апача есть свои вирутальные хосты, у nginx есть понятие server{} и эта настройка тоже содержит hostname и позволяет создать большое количество сайтов на одном сервере, то ничего подобного у того же express я не вижу. Максимум что можно сделать, это запустить несколько «серверов express» на разных портах, но это ведь не сделает их доступными в интернет. Все равно ведь нужно иметь nginx который будет принимать запросы на 80 порту, получать домен и проксировать запрос в зависимости от домена на express. Или я ошибаюсь?
— если все таки nginx действительно не используется, а сервера на продакшине представляют собой запущенный express или nuxt nitro, который сразу слушает 80 порт, то неужели эти программы действительно способны тягаться в безопасности и стабильности с гигантами и давно зарекомендовашими себя apache или nginx? Это сервисы проверенные временем и пользователями, а что такое nuxtjs nitro? Он буквально возник недавно, в документации написано что всего 9 месяцев назад его начали разрабатывать. Что мы можем знать о безопасности этого продукта?

Господа, раз уж здесь обсуждаются технологии из мира javascript, то хочу услышать ваше мнение и опыт использования jwt токенов как инструмента авторизации?
Изучаю эту технологию и честно говоря, на мой взгляд, это очень небезопасная система.
Плюс вижу, что совершенно каждый разработчик реализует логику работу с jwt по своему, кто то даже хранит их (access token) в базе, хотя по моему это полностью противоречит идее самого токена. Зачем тогда сигнатура в токене, если хранить в базе ассоциацию между пользователем и токеном, это по сути получается механизм сессий с хранением в базе.
Какую бы документацию не читал, везде встречаю фразу типа — даже если у вас украдут токен, то он позволит пользоваться сервисом не долго. Не говоря уже о том, что большинство разработчиков не ставят время жизни в 10 минут, а ставят 12 часов а то и больше, но даже 10 минут хватит, чтобы не спеша и попивая кофе выкачать например всю базу с клиентами. Ничего себе система авторизации и безопасности).

Но это мои и пока теоретические мнения. А есть у кого то реальный и положительный опыт использования токенов именно как инструмента аутентификации? Как применяете его вы? Где храните токены на клиенте? В localstorage? Разбирались ли глубоко

Собственно, почему я, человек далекий (надеюсь что это временно ) от nodejs и стеков типа MEAN, решил вообще изучить jwt. Изобретаю механизм межсерверной аутентификации. Нужно сделать, чтобы человек авторизовавшись в одном сервисе (домене и сервере), перейдя на другой сервис (домен и сервер) сохранил свою аутентификацию и был уже авторизован. Инструмент сессий для этого мало подходит, ну разве что с хранением сессии в общей базе данных, к которой будут иметь доступ все сервисы… В общем буду рад вашим идеям, я то найду и изобрету такой механизм, но чужой опыт — всегда бесценен.

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

и бекап не сделали??