мне больше всего нравится вариант hmac + рефреш + блэклист

ну и jwt как самый простой способ сделать hmac

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

а вот смысла юзать oauth я вот лично не вижу пока (если не буду делать что-то где надо третью сторону аутентировать)

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

средняя видеокарта сгенерит тебе миллиард хэшей в секунду, так как большинство пользуются паролями из top 1000 то если у тебя сольют базу пользователей, то где-то 70% всех паролей поберут где-нибудь минут за 10 (в зависимости от количества пользователей конечно)

как по мне не сложное объяснение зачем нужны медленные алгоритмы хэширования стойкие к перебору на GPU (убивают параллелизм)

а вообще этому в универах должны учить

а то я помню как мы за семестр научились только шифровать на ксорах да rsa запилили

на примитивном уровне да, а дальше? как подобрать коэффициенты того же bcrypt или argon2

на примитивном уровне да, а дальше? как подобрать коэффициенты того же bcrypt или argon2

ну дефолтнов + словарика уже хватит что бы существенно усложнить жизнь злоумышленнику)

это так сказать "базовый уровень" который должен быть

а как подбирать параметры - вот ты их подбираешь?

нет ;) ну иногда "на глаз", а так в принципе хотелсь бы понимать баланс между затратами своих серверов и затратами подбора ;)

https://github.com/bjeavons/zxcvbn-php

К проверке сложности паролей

$a = null; var_dump($a[1][2][3]); что произойдет?

notice?

а проверить?

null

неуловимый баг, сцуко

$a = [0,1,2]; foreach($a as &$v) {} foreach($a as $v) {} var_dump($a); —---------- array(3) { [0]=> int(0) [1]=> int(1) [2]=> &int(1) }

проверень на проде

не подскажете почему так?

указатель

http://php.net/manual/en/function.reset.php

не подскажете почему так?

всегда после использования переменных по ссылке делай unset

попробовал, но не помогло

Или не используй переменные по ссылке

аааа

точно

сделать ансет $v

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

чорд, вот как с этим бороться я понял, а вот как это произошло не совсем.((

magic.gif

после первого цикла у тебя $v - слинкован с последним элементов массива $a. Второй цикл когда присвает значения в $v - по сути меняет значения в последнем элементе массива $a

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

Такие грабли, за которые надо бить по лбу наместе же. Написано же не стоит использовать foreach по ссылке. Да и логично это, что пиздец какой-то. Ну надо тебе преобразовать массив, ну куча функций array_* выбираешь нужну и погнал. На крайняк for() {}

Такие грабли, за которые надо бить по лбу наместе же. Написано же не стоит использовать foreach по ссылке. Да и логично это, что пиздец какой-то. Ну надо тебе преобразовать массив, ну куча функций array_* выбираешь нужну и погнал. На крайняк for() {}

кем написано?

@miksir ох как все просто оказалось, спасибо Дмитрий!

кем написано?

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

Бред какой-то...

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

Анимированная какаха!

Такие грабли, за которые надо бить по лбу наместе же. Написано же не стоит использовать foreach по ссылке. Да и логично это, что пиздец какой-то. Ну надо тебе преобразовать массив, ну куча функций array_* выбираешь нужну и погнал. На крайняк for() {}

почему не стоит? вообще конечно есть всякие array_walk, array_map

как-то очень категорично не забывайте ансетить &$val и всё причем PHPStorm предупредит, если забыли вроде

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

зачем юзать что-то что допускает логические ошибки?

KISS

и все такое

логические ошибки допускет не "что-то", а программист

логические ошибки допускет не "что-то", а программист

именно, потому не стоит им вообще в руки давать (то есть отсекать возможность) на уровне регламента

что бы тебе потом не пришлось разбираться "где там этот удод не поставил unset"

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

Вот, серега меня понимает :)

это как спор for vs foreach. Суть не в производительности - суть в том что при использовании for надо учитывать our of range и не проиграть с условиями

все разработчики хотя бы один раз за пратику (а на самом деле не раз) ошибались в условиях циклов

если есть такой регламент - то и проблемы нет, не писать или ставить unset

если есть такой регламент - то и проблемы нет, не писать или ставить unset

ты не понял

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

и таким образом сделать код чуть-чуть чище

а мне казалось - наша обязанность объяснить как все работает, что бы он просто понял проблему и уже не делал таких косяков ;)

вместо того, что бы говорить "просто не делай так, пиши array_walk" :)

кстати, array_walk с генераторами работает?

а мне казалось - наша обязанность объяснить как все работает, что бы он просто понял проблему и уже не делал таких косяков ;)

"как работает" не отвечает на вопрос "как сделать так что бы подобного не повторялось в будущем". Расчитывать на то что человек что-то там осознает - это ну очень слабый аргумент

/stat@combot

combot.org/chat/-1001042383571

кстати, array_walk с генераторами работает?

с генераторами тебе не нужны ссылки)

"как работает" не отвечает на вопрос "как сделать так что бы подобного не повторялось в будущем". Расчитывать на то что человек что-то там осознает - это ну очень слабый аргумент

это как объяснишь ;)

это как объяснишь ;)

спор ради спора

с генераторами тебе не нужны ссылки)

генераторы могут работать со ссылками

генераторы могут работать со ссылками

то есть возвращать ссылку?)

ну клево

и что ты с ними будешь делать?*)

foreach (xrange(1, 100) as &$number) {}

зачем тебе тут может понадобиться ссылка?

вот расскажи мне

если у тебя генератор ссылки возвращает - ну ок, это на клиетский код не влияет

мы говорим про ссылки в контексте обхода коллекций/итераторов сейчас

откуда я знаю когда мне это может понадобится, когда понадобится, тогда узнаю

откуда я знаю когда мне это может понадобится, когда понадобится, тогда узнаю

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

пройтись по коллекции и сформировать новую - это дефолт

п. 2 и 3 подразумевают знания сайдэффектов

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

как минимум начать с того что бы рассказать о том чем плох стэйт и сайд эффекты)

А особо с замыканиями, которые и не замыкания вовсе. Забыл в use указать нужную или передачу по ссылке там - вот тебе тоже логическая ошибка. Кстати, а как из array_walk выйти из цикла?

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

Кто сказал "просто не делай"? Я буду говорить "не делай вот так, потому что Dmitry Mikslr сделал так и ебался с этим потом несколько дней, и погугли почему foreach c сылками это плохо" и человек все поймет ;)