• 9 полезных приёмов для тех, кто программирует на JavaScript
    0

    Заметьте, я и не говорил про спецификацию, я сказал про JS движки (V8 / Spider Monkey / etc.) и их оптимизацию такого поведения, что я не уверен, что подобное использование length не деоптимизирует байт код.


    Касаемо спеки, да, данное поведение в ней явно прописано.

  • 9 полезных приёмов для тех, кто программирует на JavaScript
    0

    Исходя из поста, знание основ любого языка — признак профессионализма.


    1. Очистка или усечение массива

    А за такое можно сразу гнать из профессии. Мало того, что это, мягко скажем, необычное применение для length, это, предполагаю, может подгадить в плане оптимизации кода JS движком. Не говоря уж о том, что JS не требует ручного управления памятью.


    4. Использование диапазонов значений в операторе switch

    А почему нельзя было через if/else?

  • Почему не стоит использовать LocalStorage
    0

    Во-первых, как уже было сказано выше, Cookie — ~4kB т.е. 4k char. В среднем, я не использовал JWT токены длинее 2k символов, но это не показатель, и ваш JWT может быть и в 8kB.


    Во-вторых, cookie постоянно гоняются по сети, даже если вы этого не хотите (fetch и XMLHttpRequest не в счет, там по умолчанию false).

  • Может ли в JavaScript конструкция (a==1 && a==2 && a==3) оказаться равной true?
    0

    Да, т.к. document.getElementById('layer1').style.opacity — это строка, а не число.


    И формально, это равносильно этому:


    let a = '0.2';
    
    a += 0.01; // Тут Number преобразуется в строку
    
    console.log(a); // => 0.20.01

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


    И Flow сделает то-же самое: https://flow.org/try/#0DYUwLgBAhhC8EHICMCDcAodMDU8BMG6AxgPYB2AziaAHTAkDmAFFAJSoQD0ncAfBEjxA

  • Может ли в JavaScript конструкция (a==1 && a==2 && a==3) оказаться равной true?
    0

    Тут трудно не согласиться (я об это тоже сказал чуть выше). Но мы все-же говорим в контексте JS.


    Собственно, надеюсь, я правильно понял вашу позицию. TS действительно крутой :).

  • Может ли в JavaScript конструкция (a==1 && a==2 && a==3) оказаться равной true?
    0

    Вы абсолютно правы, что язык должен в первую очередь быть инструментом, а не целью. Но в большинстве языков: Python — input(), C — getchar(), Ruby — gets, инпут — это строка.


    Так и в JS, input Dom node — содержит исключительно строки.

  • Может ли в JavaScript конструкция (a==1 && a==2 && a==3) оказаться равной true?
    0

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

  • Может ли в JavaScript конструкция (a==1 && a==2 && a==3) оказаться равной true?
    0

    (простите, опечатался, не "a", а конечно же "x" станет числом тоже).


    И в целом то, это проблема не JS, а вообще динамических языков, и языков с хоть чуть-чуть возможностью переопределять операторы или (и) неявно приводить типы.


    # Python
    >>> "5" * 10 + "8"
    '55555555558'

    Т.е. тут вопрос скорее к невнимательности. И тут TS или Flow, бы решили эту проблему (ну или попытались :) ).

  • Может ли в JavaScript конструкция (a==1 && a==2 && a==3) оказаться равной true?
    +1

    И нет, "a" — не останется строкой, т.к. "-" тоже кастует в Number

  • Может ли в JavaScript конструкция (a==1 && a==2 && a==3) оказаться равной true?
    +1

    Ну и сами вы себе злой буратино. Зная, что в JS такое поведение, и что input value — это всегда строка, кто мешает вам, опять же зная, что вы будете производить мат. операции над этим инпутом, самому сконвертировать.


    const a = 0.1;
    const x = +document.querySelector('input[name="x"]').value; // Вот теперь это число
    const y = +document.querySelector('input[name="y"]').value; // И это тоже
    
    console.log(x - a * y)

    Хотя parseInt(n, 10) все-же более наглядно и конвертирует исключительно в десятичное число (т.к. +'0xFF' === 255).


    По-хорошему, нужно x и y сконвертировать в число в момент присвоения

    С чего бы это? Инпут хранит исключительно значение как строку, а если вы про input[type="number"] — то это не имеет никакого отношения к JS, это лишь валидация пользовательского инпута, как и type="email", а в JS это приходит как обычная DOMString.

  • Может ли в JavaScript конструкция (a==1 && a==2 && a==3) оказаться равной true?
    0

    Если интерпретатор написан по-стандарту (и здравому смыслу), && будут идти слева-направо. V8 / SpiderMonkey / Chakra работают именно так

  • Может ли в JavaScript конструкция (a==1 && a==2 && a==3) оказаться равной true?
    +3

    Не совсем понимаю за что вас минусуют. Если вы не против, я добавлю комментарии к вашему коду, что-бы читателям стало понятно.


    Для начала, это абсолютно валидный код с точки зрения C.


    #define директива — это по-сути замена во время компиляции найденого токена (или вызова) на его значени. В случае выше, любая найденная a будет заменена на (__COUNTER__+1)


    __COUNTER__ — это "магическое" макро значение, как и __FILE__, __LINE__, или __FUNCTION_. И в C / C++ эти значения опять же заменяются на этапе компиляции (см. выше). Сам же __COUNTER__ "магичен" из-за того, что при каждом новом вызове, он будет инкриментировать свое значение (от 0).
    В итоге выражение (__COUNTER__+1) станет (0+1), затем (1+1), затем (2+1).


    И весь код будет выглядеть так:


    // Т.к. `include` тоже макрос, тут будет содержимое этого файла.
    
    int main(void) {
        if ((0+1) == 1 && (1+1) == 2 && (2+1) == 3) printf("123123123");
        return 0;
    }

    А дальше все еще круче, если кому интересно, компилятор просто схлопнет (оптимизирует) константные выражения, и на выходе останется:


    // Т.к. `include` тоже макрос, тут будет содержимое этого файла.
    
    int main(void) {
        printf("123123123");
        return 0;
    }

    Так-что не спешите кидаться на zawodskoj

  • Вашим пользователям не нужны пароли
    0

    А что, если злобный админ поставит прокси перед /api/signin и будет писать не захешированные пароли (а напомню, они именно так по сети гуляют) в файлик?


    И опять же, см. пункт с ресетом пароля, если он есть, то вы и так сможете получить письмо.

  • Вашим пользователям не нужны пароли
    0

    Могу ошибаться, но у Github синхронизация только между табами одного устройства, и скорее всего через localstorage / cookie в браузере.


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

  • Вашим пользователям не нужны пароли
    0

    Но нужно еще продумать о безопасность этого подхода, т.к. хранить только email в клиентской сессии, вообще не безопасно, нужно тогда возвращать какой-нибудь секрет от запроса, сгенерированный бэком, а также хранить его в sign_in_requests таблице.


    С хранением на бэке, примерна такая-же история, нужно будет записывать guid сессии (cookie-based сессии) в таблицу sign_in_requests, и опять же сверять при рефреше сочетание email + secret.

  • Вашим пользователям не нужны пароли
    0

    Если я вас правильно понял, вы хотите, чтобы страница (с которой отправлен запрос) сама перезагрузилась, когда вы перейдете по ссылке из письма. Идея хорошая, но тут может появиться излишние затраты либо на Long polling, либо на полноценный Web socket (запросы по таймаута — зверство, поэтому я их не рассматриваю). Но этот вариант может решить проблему с телевизорами / IoT'ами.


    Можно сделать менее красивый, но и менее затратный вариант: запоминать email на который выслали письма, а после ручного рефреша страницы (или перехода на другую страницу) проверять, перешел ли пользователь по ссылке из письма и окончательно авторизовать его. Т.е. получается такая двух этапная авторизация, на первом шаге мы просто записали email в переменную сессии (localstorage / cookie / backend session), а после подтверждения активировали эту сессию.

  • Вашим пользователям не нужны пароли
    0

    У нас есть HTTPS, а с Lets Encrypt вообще нет ни одной причины не использовать его.


    К слову, а подтверждая email переходом из того же письма, вы более устойчивы к MITM?

  • Вашим пользователям не нужны пароли
    0
    Использование внешнего сервиса — это само по себе риск, даже в не самых критичных частях системы. Вы просто никак не можете работать с этим риском и влиять на него, особенно если это крупные сервисы типа mail.ru/gmail.com/

    А что вам в предложенной схеме мешает использовать свой почтовый сервер, если вы не доверяете гуглу?


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

    К сожалению, я склонен больше верить в то, что у сайта с "котиками" будет все плохо, нежели у Yandex / Google / Mail.


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

    А почему в предложено выше варианте они не могут сосуществовать? Вы можете позволить пользователю самостоятельно сделать выбор чем он хочет пользоваться: Oauth / Email + Pass / Email.


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

  • Вашим пользователям не нужны пароли
    0

    Использовать телефон (СМС) гораздо доже и менее безопасно, чем почту.


    А если предположить, что номер телефона может утечь, то начнется спам. А вот спам на телефон в разы более мерзкий, чем на email. Если у email сервисов уже отлажены методы борьбы со спамом, то вот у телефонов все плачевно, будете получать звонки от "пирамид" с разных номеров.

  • Вашим пользователям не нужны пароли
    +1
    Автор просто предлагает переложить заботу о хранении пароля на чужие плечи.

    Так она и не слезала с их плеч. Т.е. если у вас есть сброс пароля — у вас и не было никогда пароля. Multi kill


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

    Так и вижу, как я бегаю по комнате ищя кубики, чтобы авторизоваться на хабре :).

  • Вашим пользователям не нужны пароли
    0

    То же самое, что и если пароль перехвачен по дороге.

  • Вашим пользователям не нужны пароли
  • Вашим пользователям не нужны пароли
    +1
    разве не получается. что при таком подходе ответственность за защиту пользовательских данных переходит с сервиса на емеил провайдера

    Она и так всю жизнь на них.

  • Вашим пользователям не нужны пароли
    0

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

  • Вашим пользователям не нужны пароли
    0
    Автор, который утверждает, что пользователям не нужны пароли.

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

  • Вашим пользователям не нужны пароли
    +1
    Колонку email заменить на users_id (связь по primarykey как то более привычно).

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


    Вместо колонки expiredAt, мне кажется более логично created_at (тем самым время жизни токена можно вынести в конфиг).

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


    Вместо колонки isUsed более логично использовать activated_at где писать дату входа по токену

    Вот это крутое замечание, обновил статью.


    Добавляю колонку deleted_at где можно деактировать любую запись

    Как я заметил в статье, это минимальный набор, и deleted_at более чем нужен в реальной жизни (в том числе и в таблице с пользователями), но в текущем повествовании это было лишним.

  • Вашим пользователям не нужны пароли
  • Вашим пользователям не нужны пароли
    0

    Это еще более упрощенный вариант. Но тут прямо на лицо огромная дыра в безопасности. Хотя все зависит от ваших потребностей.

  • Вашим пользователям не нужны пароли
    0

    Если разрешите позанудствовать, то "шарить" учетки, как правило, запрещено на любом сайте.


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

  • Вашим пользователям не нужны пароли
    0

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

  • Вашим пользователям не нужны пароли
    0
    Секретные вопросы

    Еще один излюбленный инструмент садиста. Я с большей долей вероятности забуду "Имя первой учительницы", чем сгенерерованный 64'ех символьный пароль.


    P.s. менеджер секретных вопросов может стать неплохим стартапом.

  • Вашим пользователям не нужны пароли
    +1
    вы перекладываете «сервис аутентификации» на сторонний ресурс

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


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

    Да, ровно как и сейчас. Если у вас взломали почту — то вы потеряете и доступ к большей части сайтов вместе с ней. Т.к. "ресет пароля".


    если у пользователя будет утерян доступ к почте/смс (забыл пароль/потерял телефон).

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

  • Вашим пользователям не нужны пароли
    0

    Охотно верю, но раньше решения предложенного вами не встречал.


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

  • Вашим пользователям не нужны пароли
    –1

    И долго вы оставались владельцем почты с паролем из 3 цифр? :)

  • Вашим пользователям не нужны пароли
    –1

    Как я сказал в заключении, этот подход непривычен. Но никто не мешает вам рассказать пользователям, как пользоваться такой "фичей".


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

  • Вашим пользователям не нужны пароли
    0

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

  • Вашим пользователям не нужны пароли
    0

    Заметьте, я не сказал ни слова против OAuth. Подход описанный выше может спокойно сосуществовать с ним (в принципе, как сейчас и происходит).

  • Вашим пользователям не нужны пароли
    –2
    Увеличивается время входа на сайт.

    Вы имеете ввиду время сессии / срок действия cookie?

  • Вашим пользователям не нужны пароли
    0

    Если не изменяет память, так делает саппорт Webmoney, он просто выдает вам токен на вход в чат.

  • Вашим пользователям не нужны пароли
    0

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