• Обсуждение: что если работать без cookies — рассказываем, какие есть альтернативы
    0
    использование отпечатков не является в данный момент нарушением? к примеру у меня отпечаток используется для безопасности — на основе отпечатка считается хэш который и посылается на сервер. это позволяет мне не беспокоиться о том, что токен аутентификации будет украден
  • Управление текстом и локализация в веб-приложении
    0
    Дели число на 10 и на 100. или следи за последними 2мя цифрами числа. если там 11-14 — окончание ев. в остальных случаях смотри последнюю цифру. там сам разберёшься. все повторяется
  • Руководство по аутентификации в Node.js без passport.js и сторонних сервисов
    0
    Для JWT не обязателен логин и пароль. Более того: пароль вообще не нужен, в прочем как и логин. Можно просто хранить id пользователя в базе. Я, к примеру, помимо id храню в JWT данные, которые не вижу смысла получать постоянно заново из базы. Например это может быть ник пользователя или дата создания аккаунта (если она вам нужна)
  • Руководство по аутентификации в Node.js без passport.js и сторонних сервисов
  • Руководство по аутентификации в Node.js без passport.js и сторонних сервисов
    +1
    Это может быть полезным для передачи, например метаданных, закодированных внутри токена. Подобные метаданные, могут описывать роль пользователя, его профиль, время действия токена, и так далее. Они могут быть предназначены для использования во фронтенд-приложениях

    Не нужен jwt для того чтобы передавать открытые данные на фронтенд.
    Дело в том, что jwt хранит первые 2 части в base64. Это позволяет легко декодировать их как раз в json (потому он так и называется). Но третья часть, подпись, не нужна на клиенте ни за чем. Если рассуждать как автор — я на клиенте должен описать примерно такую логику:
    function encodeFromJWT(token) {
      const payload = token.split('.')[1];
      return btoa(payload);
    }
    

    Я бы понял, если мог бы изначально проверить токен. Но для проверки мне надо знать секретный ключ (соль) для того, чтобы библиотека jsonwebtoken мне с ним высчитала хэш и сверила с подписью в токене, а хранение соли на клиенте равносильно подписи токена от любого источника. Как результат — использование JWT для передачи данных на клиент это велосипед, который не дает преимуществ перед обычным json.

    Так же по поводу cookies. Дело в том, что куки не просто хранилище. Они позволяют вам защитить хранимые данные или поставить им время жизни (или и то и то). Поэтому JWT храниться в куках браузера, а заменить их и подавно не может. Но для хранения аутентификации необходимо поставить флажок httpOnly, что позволит «спрятать» токен от клиентского JS. Если вы используете https-соединение стоит поставить еще флажок secure, который отключает передачу токена вне https.

    В статье еще не была названа основная фишка JWT и преимущества перед связкой login:password_hash, прилетающей на сервер например из куки, — JWT гарантирует неизменность данных, что позволяет избежать лишнего запроса к базе.

    В то же время у JWT есть минус: его не возможно отозвать. Он будет валиден даже будет украден. Это решается одним из 3х способов:
    1) хранение в JWT даты обновления пользователя в базе. При любом обновлении профиля все прошлые JWT становятся не валидными. Но тогда в чем смысл JWT если я храню дату обновления? он не дает преимуществ по сравнению с login:password_hash
    2) Хранение в базе черного списка JWT. Но для этого нужен и белый по сути — иначе не знаешь какой токен поместить в черный. Проблемы та же что и в 1м случае.
    3) Способ, который использую я: в JWT храню хэш fingerprint-а, что позволяет мне идентифицировать устройство пользователя. При запросах (важных) посылаю на сервер fingerprint, высчитываю хэш и сравниваю. Если хэши разные — устройство было изменено и аутентификация не прошла. В результате не требуется запрос к базе и мы можем быть уверены что токен не был украден.

    В дополнение JWT имеет свое поле со временем жизни. При валидации токена сравнивается не только подпись, но и это поле, что позволяет реализовать механизм access-refresh, за счет чего злоумышленника выкинет даже если он украдет аутентифицированное устройство, а пользователь сменит пароль.
  • Как я нашел свою первую уязвимость?
    0
    Вы можете перечитать статью 272. Дело в том, что нахождение уязвимости не карается законом. Вот ее использование — да, если повлекло копирование, модификацию, шифровку или удаление. В моем случае нет ничего противозаконного. Даже если бы я сообщил о ней сразу. Я не могу отвечать за действия других.
  • Как я нашел свою первую уязвимость?
    0
    Они отказались платить за уязвимость, они могли избежать всего этого и, я думаю, ваш знакомый именно это бы и сделал. + я нашел уязвимость и передал им.

    Я не имею отношения к тому, что компания по какой-то причине не может исправить уязвимость. Точно так же как не имею отношения к тому, что они валидируют ввод. Сроки не жесткие по причине того, что она фиксится в 2 щелчка. А то, что компания будет тянуть это неделями — не мое дело. Будь это мой сервис — я бы выкатил фикс уже через 5 минут. Я не ставил ультиматум — я поставил выбор, рассказал как ее исправить и дал время на исправление среди рабочей недели.

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

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

    Если за 2 дня компания не может написать одну строчку — виноваты полностью они. Была бы уязвимость с базой — я повременил бы больше. Была бы она критическая — тоже повременил бы больше. 2 дня на строчку — не жесткие сроки на мой взгляд.
  • Как я нашел свою первую уязвимость?
    0
    Спасибо, мне уже ответили. Сейчас поправлю.
  • Как я нашел свою первую уязвимость?
    +1
    Поиск уязвимостей — скорее маленькое хобби, чем способ заработка. Мне достаточно той зп, что мне платят на работе.
  • Как я нашел свою первую уязвимость?
    0
    Привет. Если интересно — можешь написать мне в лс.
  • Как я нашел свою первую уязвимость?
    +1
    Это не мой подход. Не хочу заставлять компании платить.
  • Как я нашел свою первую уязвимость?
    –2
    Тут есть несколько факторов.
    1) Это все же IT-компания.
    2) Она не работает на российском рынке и статью она навряд ли увидит
    3) Это обычная xss. Я кинул ссылку, позволяющую воспроизвести уязвимость и дал полное описание, а так же сообщил как ее закрыть. Если it-компания не может за 2 дня вставить регулярку — скорее всего компании это не нужно.

    Сейчас, кстати, я проверил наличие уязвимости. Уязвимость закрыта — блокируются пробелы и <, >. Поле для ввода промокода пропадает в случае несоответствия.
  • Как я нашел свою первую уязвимость?
    0
    Это было бы так, если бы в конце регулярки не было бы символа g. Он отвечает за то, чтобы проверить все символы строки
  • Как я нашел свою первую уязвимость?
    +2
    На самом деле я об думал. Но я не хочу ковырять их сайт. Они ясно дали понять, что оплаты не будет. Я конечно мог потребовать оплату «или я выложу это в интернет», при том, что уязвимость принимала не только html, но и js. Просто такой метод не для меня. Я решил, что отдам им уязвимость, а сам — выложу статью, дал им время на исправление.

    Подход требования оплаты против воли компании не нравится мне совсем.
    Если компанию не интересует безопасность в ее бизнесе — это ее право. Лично меня всегда интересовала безопасность данных пользователей в компании, где я работаю, как и ее владельцев.
  • Как я нашел свою первую уязвимость?
    0
    Что значит /[A-Z0-9]/g?

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

    То есть при тестировании строки через это регулярное выражение строка
    QWERTY12 пройдет тест,
    а вот QwErTy12 уже нет, так как включает строчные символы
  • Как я нашел свою первую уязвимость?
    0
    Потому я и пометил, что это не вариант.

    А здесь перебирай — не хочу

    Это на мой взгляд не важно в партнерской системе. Какая разница использует пользователь один код или другой. Основная фишка промокода — заставить посетителя сайта зарегистрироваться. С точки зрения бизнеса перебрал пользователь промокод или добыл как-то иначе абсолютно не важно.
  • Post mortem: cледи за middleware или как мы сломали комментарии
    +1
    Я конечно все понимаю, но кто глобальные переменные использует в коде? Я и сам на экспрессе работаю и никогда не было такого момента, что без них не обойтись.

    Ясное дело, что глобальная будет меняться каждый раз при ее изменении. Но все дело в том, что у вас есть объект req. Ничто не мешает его изменять, добавлять доп поля и тд. Таким образом у вас всегда для каждого запроса будут свои переменные, которые не будут переопределяться. Даже если 100500 пользователей одновременно бросят запрос на этот маршрут
  • Не умничайте с формами для входа
    0
    мобилки — понятно. Но они постоянно наращивают свои мощности и потому это уже не имеет значения.

    SEO — отдельный разговор. И для него есть свои решения: пререндер, специальные пакеты для динамического редактирования хедера и тд
  • Не умничайте с формами для входа
    0
    Как раз он самый.

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


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

    И если их мало, это происходит весьма быстро.


    Вы не работали с крупными проектами? или все писали на хтмл? Я и сам одно время писал почти все на хтмл и css. Да, в скорости одной страницы выигрываю, но в конечном счете — нет. Я уже об этом говорил. Может вообще все без жс писать? Как раз все в плюсе: менеджеры, поисковые боты, пользователи. Но в минусе — функционал
  • Не умничайте с формами для входа
    0
    Это если у клиента достаточно мощное железо, в противном случае часто всё печально.


    Не совсем так. Как я уже говорил — обновляется только то, что изменилось. В итоге рендер страниц на клиенте почти всегда рендерит лишь часть.
    И если вдруг у клиента не хватит мощности процессора на document.createElement('div') — то вообще не понимаю с чего он сидит.

    Я профессионально занимаюсь разработкой и бэкенда и клиента на реакт. И самое долгое там — передача информации от сервера к клиенту ( в виде json ). На мобильных телефонах это работает прекрасно. На планшетах тоже. Да что там? я и на электронной книге запускал (правда с электронными чернилами не проходит такое. Но тут уже особенности реализации ее). Скорее ты браузер не запустишь на устройстве с таким железом о котором ты говоришь.

    Я понимаю, может ты смотришь в сторону маил.ру и вк. Там — да. Все лагает. Но это единичный случай. ФБ использует реакт, LinkedIn тоже. Гугл использует ангуляр для своих сервисов (тот же рекламный кабинет на нем и почта новая).
  • Не умничайте с формами для входа
    0
    у тебя все привязан у номеру? на мой взгляд ВК то уж точно не заботится об анонимности и сохранении данных пользователей.

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

    по поводу спама — я сказал «одно время». надеюсь ты помнишь когда спам не фильтровался. и мне на смс спам не сдали не разу — компаниям не выгодно с тарифами текущими.
  • Не умничайте с формами для входа
    0
    вероятно вы не веб-разработчик. скрипты на клиенте выполняются быстрее по одной причине — не прилетает большая куча хтмл. Так же при перезагрузке страницы после того как прилетит весь хтмл — должны отработать скрипты.

    в итоге скорость чисто клиентского приложения выше чем при сервером рендере.

    и к тому же для реализации подобных приложений используются библиотеки и фреймворки такие как react и vue. Они имеют виртуальную модель страницы, что позволяет им обновлять только то, что действительно изменилось. за счёт этого скорость вырастает. единственное когда клиентское приложение уступает серверному рендеру — первая не кэшированная загрузка сайта (грузит все скрипты).
  • Не умничайте с формами для входа
    0
    Враки. Теперь код для формы авторизации таскается за мной каждую страницу (больше трафика).


    Все скрипты кэшируются при первой загрузке этого скрипта (для чего и делают билд фронтенда)

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


    Какой скрипт у вас грузится каждый раз заново? кроме конечно метрик.

    По поводу перезагрузки страниц: избавиться от перезагрузки страниц помогает приложение с клиентским рендерингом (ну например create-react-app). Это позволяет однажды загрузить все скрипты и стили при первой загрузке сайта. После чего это все кэшируется. В результате у вас нет (вообще нет) перезагрузки страниц в браузере. И это позволяет выиграть в скорости. Сразу видно, что вы этими технологиями не особо интересуетесь.
  • Не умничайте с формами для входа
    0
    Ок. Почему ты готов предоставить эмаил и не предоставить номер телефона? Разве и тот и другой не позволяет связаться с тобой?

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

    Почему-то все смирились со спамом на почту одно время, но не могут смириться что их номер куда-то уйдет.
  • Не умничайте с формами для входа
    –1
    Нет. Вместо даже заполнения двух полей руками и нажатия отправить я должен заполнить поле, переключится на мышку для нажатия далее, заполнить ещё одно поле и уж тогда только авторизоваться.


    Что мешает нажать энтер?

    Вызывает тонны ненависти. Особенно когда начинают вымогать номер телефона на последнем шаге, мол, раз уж потратил кучу времени на заполнение других полей, то бросать будет жалко. НЕНАВИСТЬ! Использую магическую комбинацию Ctrl+W для прекращения этого безобразия


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

    Они не привязаны к дизайну. Они привязаны к разметке. Нужны человеческие input с человеческими name.


    Ой. А может перестанем использовать жс вообще? реакт тот же. Спецом под рукожопов, которые не могут написать менеджер нормально. Как раз тогда решится эта проблема — без name ничего не вытащишь с запроса. Пора перейти обратно к вебу 2000-х годов. Ведь современный веб мешает криворуким разработчикам менеджеров паролей!
  • Не умничайте с формами для входа
    –2
    Думаю стоит посмотреть в реализацию менеджеров паролей а не в веб.

    По ряду причин:
    1) Веб существует давно и все не побегут переписывать свои сервисы чтобы менеджерам было удобнее
    2) Гугл предоставляет свой менеджер, который (по крайней мере у меня) прекрасно справляется и с постраничной и с модальной формами
    3) Это удобно для компаний — пользователя, который запутается в постраничной форме едва ли удастся найти
    4) Многие крупные компании используют подобное (гугл, яндекс, скуп и тд.)
    5) Это удобно для пользователей

    По поводу 5 пункта отдельный аргумент:

    #1 — Модальное окно
    Представим вы посещаете агрегатор товаров со сравнением цен с разных площадок и кэшбэком. Вы долго бродите по страницам, открываете кучу вкладок и вот вы выбрали тот самый товар, который вы хотите приобрести. Но, чтобы получить кэшбэк надо войти на сайт. Вы переходите по ссылке в хэдере, логинитесь/регистрируетесь, снова ищите этот товар чтобы купить его.
    1. Как решается это в веб сейчас без модального окна:
      • Добавляется querystring с uri редиректа — удобно, но слетает после перехода по любой ссылке на сайте.
      • Пишется в куки последний посещенный товар — удобно только до того момента пока вы не передумаете покупать этот товар. Вы перехотели брать товар, но сайт вам понравился — погружаете ноутбук в сон и идете спать (без закрытия браузера); На следующий день открываете ноутбук, регаетесь и вас кидает на предыдущий товар даже если предварительно вы ходили например посмотреть условия пользования или на главную. Да и выглядит это как баг, а не как удобная фича.
        Хотите добавить кукам время жизни? — пожалуйста. Но я ведь могу отойти и потом не получить редирект на старый товар. То есть работа данного метода не равна 100%

    2. Проблемы при этом:
      • не удобно;
      • устарело;
      • лишний трафик для загрузки хтмл (особенно на мобильных устройствах);
      • долго для пользователя;
      • Что дает модальное окно:
        • Отсутствие перезагрузки страницы (меньше трафика)
        • Быстрее работает сайт (опять же все сводится к загрузке страницы и отработке всех скриптов)
        • Не теряется найденный товар. Поместил в хэдер — логин и регистрация работает с любой страницы. Как следствие: где зарегался — там и остался



      #2 — Постраничная форма
      Простой интернет-магазин но без постраничной формы. Требует много полей
      1. Как решается это в веб сейчас без постраничной формы:
        • Создается огромная форма
        • Пользователи вводят поля друг за другом и жмут «далее»
        • Пользователи вводят поля на одной странице и жмут «далее»
        • Сервер обрабатывает — выдает ответ.

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



        На мой взгляд модальные окна и формы в них видны в хтмл. А значит их можно заполнить.
        Да и вообще не думаю что менеджеры должны быть привязаны к дизайну. В таком случае они уж слишком сильно ограничивают компании. Может на сайтах перестать менять дизайн из-за них? А то мало ли — слетит все. Если бы так все думали — мы бы до сих пор сидели с дизайном 2000-х.
        По-моему, раз уж менеджеры работают с приложениями и сайтами, необходимо улучшать их. Они должны подстраиваться под разный дизайн. И тогда не будет таких проблем.

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

        Буду рад услышать ваши доводы в поддержку статьи.
  • NestJS - тот самый, настоящий бэкенд на nodejs
    0
    Да. идея примерно похожая.
  • NestJS - тот самый, настоящий бэкенд на nodejs
    0
    К сожалению выложить ее не получится. Как я и говорил, она была переписана на экспресс. Но если вы приведете пример кода, где можно для одного маршрута, работающего с graphQL вызывать или не вызывать мидлвэр — думаю вы развеите мои сомнения.

    Вся сложность была именно в том, что я не мог в нужном мне случае вызвать мидлвэр из-за того, что прописывать их необходимо у черта на куличках в строго установленном месте и так просто его не вызовешь. И смысл этого мидлвэра, что он имеет уже строгий ответ, который вернет если пользователь не аутентифицирован, а должен быть. То есть меня не устраивает функция. Он должен либо пропустить запрос, либо нет.
  • NestJS - тот самый, настоящий бэкенд на nodejs
    –2
    Действительно нест заслуживает свое место. Но у него есть свои проблемы.

    Я работаю fullstack nodejs разработчиком в американской компании. По большей части я — бэкендер, но мои знания фронтенда позволяют мне немного разнообразить разработку.

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

    Ближе к делу:
    3-4 месяца назад мы разрабатывали биржу гифт-карт для амазон. Проект не сложный и я решил попробовать нест для него. Меня очень быстро ждало разочарование и вот почему: я стараюсь не использовать сторонние модули (например не вижу смысла подключать пасспорт, если я создам более легкую и быструю реализацию за час-полтора). С нестом такое не проходит.

    Я, как любитель хороших технологий, связываю с нестом graphql. Кто пробовал соединять — поймет о чем я говорю: нужно посадить резолвер для последующей обработки пришедших данных. И вот тут то мне и нужно проверить аутентификацию (если ее нет — вернуть ошибку, если есть — пройти дальше, записав в какой-то общий объект идентификатор пользователя). В экспресс это делается в 2 счета, а в нест так не пройдет. Обычно я в объект запроса я пишу id пользователя для удобного доступа к данным. Если в нест и записать так, то получить потом из обхекта запроса не сможешь ничего из-за строгой структуры файлов проекта.
    Решение в документации на основе passport, но как я уже говорил, его я ставить не намерен. Потеряв 1,5 дня на этом моменте я принял решение переписать проект на экспресс, что заняло те же 1,5 дня.

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


    Минусы:
    • Силшком сильно режет возможности, что не позволяет писать свои реализации пакетов вроде пасспорт
    • Абсолютно не подходит для разработки json-api