Был вопрос про пример – я написал простейший пример, чтобы было понятно, о чём речь. Можешь по аналогии свой пример придумать, если этот не нравится. Мне – лень.
Я и сейчас скажу, что обвинять в чём-то людей, ничего не понимая в предмете обсуждения – это глупости. А дальнейший разговор меня в этом ещё больше убедил, оппонент продемонстрировал полное непонимание предмета. И никакие твои рассуждения про то, как что-то где-то может случиться, меня в этом не переубедят.
Это ты не понял, почитай дальше. Тот персонаж начинает сходу всех обвинятьв том, что у них капча, что они ничего другого не знают, а вот у него, продвинутого, дополнительные поля.
Хотя как раз дополнительные поля – это вообще не для этого случая, от слова "совсем".
И дальше какая-то муть про обработку в обработчике, на который не надо пускать. 🤪
SeVlad: Так при каком из вариантов на обработчик прилетит такая херня как у ТС, минуя родную форму? Правильно только при п 2! Таким образом если бы была реализована какая-то защита ДО отправки на обработчик, то проблемы просто бы не существовало. Именно об этом и было сказано.
Да неужели? А я что-то не заметил, по мне - так как раз наоборот было сказано.
SeVlad: Тут "капча" - как метод отсеивания ботов. Будь то хоть скрытое поле, хоть nonce, хоть анализ данных - это уже вторично
Это не вторично. Это совершенно разные методы, и работают по-разному.
MkrtElion: Разве транзакции БД не помогут в этом деле?
Транзакции вообще-то происходят при любых записях в БД. Но в простых CMS удовлетворяются автоматическими коммитами, никто не морочит себе голову управлением транзакциями. А в многопользовательских CMS приходится заморачиваться. Не заморочишься - получишь упомянутые "косяки".
MkrtElion: Ну и в свете всего вышесказанного думаю что тут дело не движке в "умельце"
А движки кто делает? И это простейший пример. В многоюзерском движке при последовательных операциях с несколькими таблицами всегда следует учитывать возможность одновременных запросов, просто знать и учитывать. Это не делается автоматически, это делается программистом. Об этом и речь, а не о каких-то там "суперсложностях".
SeVlad: Нет ничего плохого и тем более глупого, что кто-то расширил вопрос и начал с возможного первоисточника проблемы.
Ну давай ещё расширим вопрос. Расскажем про дизайн формы, расскажем, как настраивать почтовые ящики... Чё плохого-то? Информация жеж! Только в этом потоке абсолютно ненужной информации теряется и замазывается суть проблемы, разговор уводится в сторону.
Я понимаю, когда речь идёт о "проблеме молотка", но здесь – даже близко не тот случай, потому что такие атаки никто не делает путём заполнения форм на сайте, запросы отправляют непосредственно на обработчик.
И главное – сразу сделан наезд на программиста, тупо и необоснованно.
Но:
https://dev.mysql.com/doc/refman/8.0/en/information-functions.html#function_last-insert-id
Был вопрос про пример – я написал простейший пример, чтобы было понятно, о чём речь. Можешь по аналогии свой пример придумать, если этот не нравится. Мне – лень.
Если выбирать из этих двух, то по стилю общения я за Милторга.
Ни разу не похож. У него вообще менталитет другой.
Ты же начал про глупости
Я и сейчас скажу, что обвинять в чём-то людей, ничего не понимая в предмете обсуждения – это глупости. А дальнейший разговор меня в этом ещё больше убедил, оппонент продемонстрировал полное непонимание предмета. И никакие твои рассуждения про то, как что-то где-то может случиться, меня в этом не переубедят.
Я тебе о том и толкую - ты не правильно понял
Это ты не понял, почитай дальше. Тот персонаж начинает сходу всех обвинятьв том, что у них капча, что они ничего другого не знают, а вот у него, продвинутого, дополнительные поля.
Хотя как раз дополнительные поля – это вообще не для этого случая, от слова "совсем".
И дальше какая-то муть про обработку в обработчике, на который не надо пускать. 🤪
Короче, мрак и хаос.
Так при каком из вариантов на обработчик прилетит такая херня как у ТС, минуя родную форму? Правильно только при п 2!
Таким образом если бы была реализована какая-то защита ДО отправки на обработчик, то проблемы просто бы не существовало. Именно об этом и было сказано.
Да неужели? А я что-то не заметил, по мне - так как раз наоборот было сказано.
Тут "капча" - как метод отсеивания ботов. Будь то хоть скрытое поле, хоть nonce, хоть анализ данных - это уже вторично
Разве транзакции БД не помогут в этом деле?
Транзакции вообще-то происходят при любых записях в БД. Но в простых CMS удовлетворяются автоматическими коммитами, никто не морочит себе голову управлением транзакциями. А в многопользовательских CMS приходится заморачиваться. Не заморочишься - получишь упомянутые "косяки".
как же отправлять ключи от капчи без этого?
Про капчу – это только у тебя и у Надежды. У ТС – ни слова. Предлагаешь ещё и указанное тобой преимущество капчи обсудить в этой теме? 🍿
свести несколько классов с одними и теми же свойствами в одно целое и т.п.?
и написать код "с нуля" в соответствии с предложенным дизайном.
Ну и в свете всего вышесказанного думаю что тут дело не движке в "умельце"
А движки кто делает? И это простейший пример. В многоюзерском движке при последовательных операциях с несколькими таблицами всегда следует учитывать возможность одновременных запросов, просто знать и учитывать. Это не делается автоматически, это делается программистом. Об этом и речь, а не о каких-то там "суперсложностях".
Нет ничего плохого и тем более глупого, что кто-то расширил вопрос и начал с возможного первоисточника проблемы.
Ну давай ещё расширим вопрос. Расскажем про дизайн формы, расскажем, как настраивать почтовые ящики... Чё плохого-то? Информация жеж! Только в этом потоке абсолютно ненужной информации теряется и замазывается суть проблемы, разговор уводится в сторону.
Я понимаю, когда речь идёт о "проблеме молотка", но здесь – даже близко не тот случай, потому что такие атаки никто не делает путём заполнения форм на сайте, запросы отправляют непосредственно на обработчик.
И главное – сразу сделан наезд на программиста, тупо и необоснованно.