Sitealert: Это не вторично. Это совершенно разные методы, и работают по-разному.
Методы/виды капчи вторичны в контексте нашего обсуждения. Тк цель любых - не отправить данные от ботов на обработчик.
А сама "капча" - только один из методов отсева злодеев. Наряду с которым может применяться и анализ введённых/переданных данных. А также может быть реализовано и их преобразования.
Sitealert: Про капчу – это только у тебя и у Надежды. У ТС – ни слова.
..И только между строк.. Как возможный дополнительный фактор.
Но теперь давай подумаем. Есть два варианта:
1. У ТСа есть капча.
2. У ТСа нет капчи.
При этом не важно какая именно "капча". Тут "капча" - как метод отсеивания ботов. Будь то хоть скрытое поле, хоть nonce, хоть анализ данных - это уже вторично
Так при каком из вариантов на обработчик прилетит такая херня как у ТС, минуя родную форму? Правильно только при п 2!
Таким образом если бы была реализована какая-то защита ДО отправки на обработчик, то проблемы просто бы не существовало. Именно об этом и было сказано.
Sitealert: потому что такие атаки никто не делает путём заполнения форм на сайте, запросы отправляют непосредственно на обработчик.
И тут ты тоже не прав. Да, чаще так и есть, но а) не всегда (и вот - как же отправлять ключи от капчи без этого?) и б) никто точно не знает как в реальности происходит у ТС. Возможно даже сам ТС.
Solmyr: Потому что фактически один юзер - одна роль. Для каждого юзверя список объектов к которым есть доступ - разный. Причем даже не только просто юзер имеет доступ к своим объектам, а к своим "плюс" - где плюс просто разный список для разных юзеров
Понятно. Тогда возможно и правда не стоит городить лишний уровень (хотя это гибче и на перспективу).
НО! Когда надо
Solmyr: сделать что-то с объектом (редактировать, комментировать, удалить, голосовать, скрыть)
то это уже речь о возможностях (capabilities) ролей/юзеров. И тут опять же зависит от того, нужно ли их разделать по уровню доступа. Если да, то надо бы их вводить. ИМХО.
Да неужели? А я что-то не заметил, по мне - так как раз наоборот было сказано.
Я тебе о том и толкую - ты не правильно понял и вскипел :)
Это не вторично. Это совершенно разные методы, и работают по-разному.
Методы/виды капчи вторичны в контексте нашего обсуждения. Тк цель любых - не отправить данные от ботов на обработчик.
А сама "капча" - только один из методов отсева злодеев. Наряду с которым может применяться и анализ введённых/переданных данных. А также может быть реализовано и их преобразования.
Вот этой хрени - <meta canonical= > Тоже не должно быть, хотя бы потому, что Яндекс, большее не учитывает эту запись
Такой херни действительно быть не должно.
Должно быть rel canonical="...". Но яндекс, как и гугл может её не учитывать при некоторых условиях.
для сохранения подобных символов применяется кодировка utf8mb4.
Причем некоторых японческих только в utf8mb4_unicode_520 ;)
в индексе одновременно несколько дублей одной страницы
В индексе ЧЕГО? По какому запросу?
Про капчу – это только у тебя и у Надежды. У ТС – ни слова.
..И только между строк.. Как возможный дополнительный фактор.
Но теперь давай подумаем. Есть два варианта:
1. У ТСа есть капча.
2. У ТСа нет капчи.
При этом не важно какая именно "капча". Тут "капча" - как метод отсеивания ботов. Будь то хоть скрытое поле, хоть nonce, хоть анализ данных - это уже вторично
Так при каком из вариантов на обработчик прилетит такая херня как у ТС, минуя родную форму? Правильно только при п 2!
Таким образом если бы была реализована какая-то защита ДО отправки на обработчик, то проблемы просто бы не существовало. Именно об этом и было сказано.
Этот пример кажется надуманным.
А ситуация когда пост правится одновременно модератором(и) и юзером тоже надумана?
А эти картинки тоже ни о чем не говорят?:
Если и после этого кажется "надумано", то тогда пожалуй только троеперстие сможет помочь. И то я не уверен.
А причём тут клиенты сайта? =)
Ничё ты не понимаешь.. Всё дело в подписи на сёрче ;)
FoxCloud, вас, кажется уже предупреждали о назойливости. Уверены, что хотите получить автозамену названия хостинга на звёздочки?
потому что такие атаки никто не делает путём заполнения форм на сайте, запросы отправляют непосредственно на обработчик.
И тут ты тоже не прав. Да, чаще так и есть, но а) не всегда (и вот - как же отправлять ключи от капчи без этого?) и б) никто точно не знает как в реальности происходит у ТС. Возможно даже сам ТС.
Потому что фактически один юзер - одна роль. Для каждого юзверя список объектов к которым есть доступ - разный. Причем даже не только просто юзер имеет доступ к своим объектам, а к своим "плюс" - где плюс просто разный список для разных юзеров
Понятно. Тогда возможно и правда не стоит городить лишний уровень (хотя это гибче и на перспективу).
НО! Когда надо
сделать что-то с объектом (редактировать, комментировать, удалить, голосовать, скрыть)
то это уже речь о возможностях (capabilities) ролей/юзеров. И тут опять же зависит от того, нужно ли их разделать по уровню доступа. Если да, то надо бы их вводить. ИМХО.
Как это все связано с коллизиями?
Если тебе хочется узнать а не снова потроллить, то вот:
Это хорошо и доступно описано в принципах построения хайлоад-приложений.
И начать с изучения термина "коллизии".