igossmart, Math работает быстро, если используются отрицательные числа, то здесь выбирай между
Math.floor - который преобразовывает к меньшему -5.12 = -6
и Math.trunc - который преобразовывает к нулю -5.12 = -5, ну или можно сказать тупо обрезает, в твоем случае это будет то что надо
Alide, Я вот только не понял зачем второй раз цеплять одни и теже элементы, это ведь все также продукты.
var els = document.querySelectorAll("a[href='/products/962112']");
for (var i = 0, l = els.length; i < l; i++) {
els[i].style.height = els[0].style.height;
}
если хочешь можешь условие добавить по типу иф i !== 0, но оно нафиг не нужно
LamerFromSpace, не существует безопасных методов передачи данных, хоть по инету, хоть написанных на бумажке из рук в руки, поэтому здесь ограничения только в степени паранойи, перехешировать можно все вдоль и поперек по нескольку раз, но это никогда не сделает передачу чего-либо безопасной. Для снижения рисков опасности "прочтения" трафика и была придумана его шифрация в виде ssl, я думаю проще тебе прочитать в гугле что это такое, но для ответа на твой вопрос: без разницы как ты будешь передавать пароль на сервер, у тебя трафик будет либо шифрованный, либо нет и все.
LamerFromSpace, через тотже certbot можно в пару кликов создать себе валидный сертификат на домен, а потом просто банально загугли как сделать базовую авторизацию, на основе нее в дальнейшем можешь извратиться и с jwt и любой ереси какую сам пожелаешь.
LamerFromSpace, просто для более четкого понимания: при открытии страницы логина в брауезере, в адресной строке сайт начинается с http или https ? И стоит ли там зеленый замок ?
Теоретически можно хоть 10 таких хендшейков сделать, типа сгенерировать рандомную строку, отправить клиенту, тот отправит обратно, если такая строка есть, то сгененировать новую и так по кругу N раз. Если задача просто прогреть сервер, то вполне нормальное решение, но безопасности оно врятле прибавит. Я бы посоветовал 2факторную уж тогда подключить, если хранятся коды пентагона.
Соответственно если все норм подтвердилось, можно потом хоть сам хеш пароля в куку записать и подтвердить валидность конкретной куки КФ, ну тоесть замапить (или как там это называется) что вот это конкретная кука прошла авторизацию и если вместе с ней придет например кука myPassword, то можно смело сравнивать ее с паролем. Либо создать токен SHA512("_cfCookie" + "password_hash") и при запросах сравнивать уже их.
GET /login
сервер генерит у себя какую то соль и привязывает ее к куки КФ, отсылая копию клиенту.
клиент отсылает пароль, зачемто вхлам захешированный всяким мусором
сервер при этом создает ровно такой же хеш и они сравниваются.
Если я все понял ровно так как написал выше, то тут скорее у меня возникает вопрос - на кой хер ? Мало того что алгоритм клиенте показывается, хоть это и пофиг, но для чего делать такую работу и чем не устраивает стандартный механизм держания пароля SHA512("соль + пасс") и просто сравнивать его с тем что приходит ?
Не совсем понял что значит "размещенный за кф", вы просто днс там держите ? https тоже от клауда ? не заметил нигде даже упоминания о сертификатах ssl, какбы какой смысл замарачиваться с хешированием паролей, если трафик голый.
Math.floor - который преобразовывает к меньшему -5.12 = -6
и Math.trunc - который преобразовывает к нулю -5.12 = -5, ну или можно сказать тупо обрезает, в твоем случае это будет то что надо