Comments 227
На onSubmit формы повесить функцию, считающую хэш от всех значений формы, и записывающую в hidden поле. На стороне сервера — проверяем, бот может полениться и не обработать JS :-)
Спасибо, отличный способ! Можно даже хеш подсолить «секретной» строчкой.
UFO just landed and posted this here
Людей с отключенным JS — меньше процента, если судить по посещаемости больших сайтов.
Для сайтов большинства присутствующих на Хабре — это меньше одного человека в день.
Ну и никто не мешает в <noscript> написать предупреждение для таких товарищей.
Для сайтов большинства присутствующих на Хабре — это меньше одного человека в день.
Ну и никто не мешает в <noscript> написать предупреждение для таких товарищей.
увы, но девелоперы с вашей логикой меня заебали.
Согласен, сознательно, а не случайно, делать ресурс недоступным для части пользователей — это клиника. Ладно, когда это ещё — домашняя страничка, а если крупный ресурс? На вконтакте.ру, видимо, тоже так же считают — часть функционала в моём браузере вообще никак не работает.
Врядли администрацию Вконтакте очень тревожит этот факт.
Судя по качеству ресурса вообще — они наверняка просто не думали об этом. Здесь же многие сторонники решения понимают, что некоторые пользователи не смогут воспользоваться их ресурсом при таком выборе, и всё равно его пиарят.
Мой предыдущий коммент и родительский оценены отрицательно, но оппоненты ничем не смогли аргументировать свою позицию. Нахожу в этом подтверждение мнения о том, что рынок в IT клонится в сторону быстрого производства продуктов крайне низкого кчества, рассчитанных на большинство вместо того, чтобы выпускать продукты качественные и соответствующие стандартам.
Поскольку оценивающих было много, объясню подробней:
При подходе, ориентированным на качество, критическая ошибка — это не когда сайт выглядит некрасиво в одном из браузеров (например, в IE), а когда им вообще нельзя воспользоваться. Клиенты ходят на сайты, как правило, за информацией, а не дизайн разглядывать.
При подходе «делаем какашку быстро и за копейки» приоритеты расставляются, конечно, иначе.
Например, меню на JavaScript сайте www.lib.tsu.ru/ в принципе не работает в konqueror, я даже не знал бы, что оно там есть, если бы мне как пример сайта не показывали это в IE. Это — критическая ошибка.
На это же сайте я вижу пустые белые полосы, разрезающие картинку. Это даже не ошибка, это — мелочи.
Оценивающим — высказывайте аргументы.
Мой предыдущий коммент и родительский оценены отрицательно, но оппоненты ничем не смогли аргументировать свою позицию. Нахожу в этом подтверждение мнения о том, что рынок в IT клонится в сторону быстрого производства продуктов крайне низкого кчества, рассчитанных на большинство вместо того, чтобы выпускать продукты качественные и соответствующие стандартам.
Поскольку оценивающих было много, объясню подробней:
При подходе, ориентированным на качество, критическая ошибка — это не когда сайт выглядит некрасиво в одном из браузеров (например, в IE), а когда им вообще нельзя воспользоваться. Клиенты ходят на сайты, как правило, за информацией, а не дизайн разглядывать.
При подходе «делаем какашку быстро и за копейки» приоритеты расставляются, конечно, иначе.
Например, меню на JavaScript сайте www.lib.tsu.ru/ в принципе не работает в konqueror, я даже не знал бы, что оно там есть, если бы мне как пример сайта не показывали это в IE. Это — критическая ошибка.
На это же сайте я вижу пустые белые полосы, разрезающие картинку. Это даже не ошибка, это — мелочи.
Оценивающим — высказывайте аргументы.
Просто никто не хочет тратить драгоценное время ради 1% аудитории, обрабатывая сотни случаев для них… + отказываться от полезного функционала.
В таких случаях это уже проблема пользователя…
В таких случаях это уже проблема пользователя…
Почему сотни? Разве не достаточно всего лишь следовать стандартам? Похоже, нужен конкретный пример.
Я делал серверную и клиентскую локигу на beta.libra.nsu.ru. Относительно навигации по меню работа закончена (кроме синхронизации с URL при навигации, как в gmail).
Попробуйте выключить JavaScript — меню будет работать.
Попробуй выключить CSS — сайт работает.
Контент подгружается через AJAX, только если это возможно.
Меню работает под JavaScript, только если это возможно.
В админке подгружается WYSIWYG-редактор, только если это возможно.
Это мой первый сайт, но мне не стоило почти никакого труда сделать независимость от JS и CSS, ведь в моём случае это только 6 дополнительных строчек кода. Неужели это сложно для профессионалов?
Я делал серверную и клиентскую локигу на beta.libra.nsu.ru. Относительно навигации по меню работа закончена (кроме синхронизации с URL при навигации, как в gmail).
Попробуйте выключить JavaScript — меню будет работать.
Попробуй выключить CSS — сайт работает.
Контент подгружается через AJAX, только если это возможно.
Меню работает под JavaScript, только если это возможно.
В админке подгружается WYSIWYG-редактор, только если это возможно.
Это мой первый сайт, но мне не стоило почти никакого труда сделать независимость от JS и CSS, ведь в моём случае это только 6 дополнительных строчек кода. Неужели это сложно для профессионалов?
Пока Вы делаете говнофункционал для 10% юзеров, тратя на него 90% времени разработки, Ваши конкуренты тратят 10% времени и выпускают бету, удовлетворяющую 90% пользователей. И завоевывают рынок. А Вы делайте, делайте.
Ничего личного, просто бизнес.
Когда Вы будете делать свой сотый сайт, Вы возможно придете к такой же мысли.
Ничего личного, просто бизнес.
Когда Вы будете делать свой сотый сайт, Вы возможно придете к такой же мысли.
Ваша мысль мне ясна. Хотя в оригинале говорилось о 90% функционала 10% средствами, а не о том, что 10% пользователей не смогут в принципе воспользоваться ресурсом. Впрочем, есть отличная цитата и на ваш случай:
«Лучше получить удовлетворительное решение, но в срок, чем полное к тому времени, когда оно станет бесполезным».
По поводу цифр о 90% времени — я уже привёл их для себя. Включил голову и дописал 6 строчек кода. Что я делаю неправильно?
Я правильно понял, что вы считаете, что делать JavaScript ненавязчивым профессионалам(!) даётся с трудом?
«Лучше получить удовлетворительное решение, но в срок, чем полное к тому времени, когда оно станет бесполезным».
По поводу цифр о 90% времени — я уже привёл их для себя. Включил голову и дописал 6 строчек кода. Что я делаю неправильно?
Я правильно понял, что вы считаете, что делать JavaScript ненавязчивым профессионалам(!) даётся с трудом?
Впрочем, есть отличная цитата и на ваш случай
Скорее, на Ваш. Эт именно то, о чём я написал.
По поводу цифр о 90% времени — я уже привёл их для себя. Включил голову и дописал 6 строчек кода. Что я делаю неправильно?
Если для Вас в рабочих js-фреймворках нашлась нужная функциональность — Вам повезло. Не у всех такие простые решения возможны в силу ряда причин.
Простой пример (правда, мало кому приходящий в голову в силу отсутствия необходимого опыта): аякс-запросы, написанные в 6 строчек, могут никак не сказаться на нагрузке сервера, на котором крутится Ваш хомячок, и дать очень большую нагрузку на сайте с несколькими сотнями тысяч хитов в час. И там уже придется подумать и реализовать схему кеширования, подходящую для такого случая. И 6 строчками вызова функций стандартного js-фреймворка не обойтись, к сожалению. И несколькими минутами времени тоже. И вполне возможно, что проще не реализовывать на первом этапе разработки проекта функциональность, которая требует существенного времени на программирование. Как бы красиво это бы не было.
У меня наоборот — 6 строчек сделали AJAX-функциональность, доступную и без JS, что и было целью после того, как были поняты ограничения JS.
В целом AJAX даёт меньшую нагрузку на сервер, чем генерация полноценных страниц хотя бы за счёт отсутствия необходимости применения шаблонизатора и подсчётом всех параметров шаблона. Кое-где в одном из проектов, где я учавствую, мы используем даже передачу данных через TCP-сокет в веб-страницах нашего приложения вместо AJAX-запросов, чтобы сэкономить на производительности сервера и уменьшить время реакции.
Но в целом, пожалуй, вы мои аргументы по поводу спора о правильности/неправильности использования навязчивого JS не приняли, но поняли, как и я — ваши.
В целом AJAX даёт меньшую нагрузку на сервер, чем генерация полноценных страниц хотя бы за счёт отсутствия необходимости применения шаблонизатора и подсчётом всех параметров шаблона. Кое-где в одном из проектов, где я учавствую, мы используем даже передачу данных через TCP-сокет в веб-страницах нашего приложения вместо AJAX-запросов, чтобы сэкономить на производительности сервера и уменьшить время реакции.
Но в целом, пожалуй, вы мои аргументы по поводу спора о правильности/неправильности использования навязчивого JS не приняли, но поняли, как и я — ваши.
В целом AJAX даёт меньшую нагрузку на сервер, чем генерация полноценных страниц хотя бы за счёт отсутствия необходимости применения шаблонизатораВы, видимо, используете какой-то неправильный шаблонизатор.
Время работы правильного не должно быть больше времени получения параметров для него. А шаблоны для использования ajax-приложениями не такие тяжелые. Пример не засчитан.
А я вот скажу, что когда AJAX-запросов становится очень много, они существенно снижают число свободных процессов сервера-бекенда, что никак не улучшает производительность системы в целом. И поэтому AJAX-запросами проще «уложить сервак». Парируйте :)
мы используем даже передачу данных через TCP-сокет в веб-страницах нашего приложения вместо AJAX-запросовВы явно путаетесь в терминологии, потому что в этой фразе мешаете мягкое с кислым. Что такое, по-вашему, ajax-запрос, как не соединение браузера с TCP-сокетом веб-сервера? Не заставляйте меня Вас прилюдно позорить :)
>А я вот скажу, что когда AJAX-запросов становится очень много, они существенно снижают число свободных процессов сервера-бекенда
Смотря вкаких случаях. Если, скажем, по клике на элемент грузится только необходимый контент, если JS включен или полностью перезагружается страница, если он выключен (а именно так, как я понимаю, и должно происходить при использовании ненавязчивого JS), то количество запросов для обоих случаях не изменится, но AJAX-запросы для сервера будут легче, ибо остальной контент рендерить серверу не придётся. К тому же перезагрузка страницы вызывает как минимум проверку на обновление некоторых статических данных — скриптов, картинок, стилей.
> Вы явно путаетесь в терминологии
Ничуть, я считаю, что достаточно неплохо владею теорией по сетям. AJAX-запрос — это не TCP-сокет функционально — например, вы не можете, например, в одностороннем порядке передать данные от сервера к клиенту (давайте comet, js.io, выталкивания буфера в постоянно грузящейся веб-странице и прочие плохо работающие вещи, мы учитывать не будем). TCP и AJAX — это разные уровни сетевых технологий, причём более высокоуровневая из них предоставляет меньшие возможности. В частности, не будем забывать, что в AJAX запросы архитектурно асинхронные, это означает возможное несовпадение порядка запросов и ответов от сервера, что не всегда приемлимо. В частости, по упомянутой мною ссылке есть такая проблема — если быстро тыкать мышой на пункты меню, может возникнуть ситуация, когда ответ на непоследний запрос будет последним и браузер покажет пользователю не то, что он хотел. Запрещать повторную отсылку запроса только потому, что не пришёл ответ на ещё один на ту же группу данных не есть хорошо. Я не говорю, что проблема нерешаемая — но в TCP такого нет.
Есть более серьёзный проект, в котором зажержки из-за периодического открытия TCP-соединений (сразу скажу — про существование перманентного соединения в HTTP/1.1 я тоже знаю) для AJAX-запросов — это плохо. Поскольку почти во всех браузерах существует способ в некоторых случаях открыть TCP-соединение, мы предпочитаем использовать его, и только в противном случае подключаем AJAX.
Смотря вкаких случаях. Если, скажем, по клике на элемент грузится только необходимый контент, если JS включен или полностью перезагружается страница, если он выключен (а именно так, как я понимаю, и должно происходить при использовании ненавязчивого JS), то количество запросов для обоих случаях не изменится, но AJAX-запросы для сервера будут легче, ибо остальной контент рендерить серверу не придётся. К тому же перезагрузка страницы вызывает как минимум проверку на обновление некоторых статических данных — скриптов, картинок, стилей.
> Вы явно путаетесь в терминологии
Ничуть, я считаю, что достаточно неплохо владею теорией по сетям. AJAX-запрос — это не TCP-сокет функционально — например, вы не можете, например, в одностороннем порядке передать данные от сервера к клиенту (давайте comet, js.io, выталкивания буфера в постоянно грузящейся веб-странице и прочие плохо работающие вещи, мы учитывать не будем). TCP и AJAX — это разные уровни сетевых технологий, причём более высокоуровневая из них предоставляет меньшие возможности. В частности, не будем забывать, что в AJAX запросы архитектурно асинхронные, это означает возможное несовпадение порядка запросов и ответов от сервера, что не всегда приемлимо. В частости, по упомянутой мною ссылке есть такая проблема — если быстро тыкать мышой на пункты меню, может возникнуть ситуация, когда ответ на непоследний запрос будет последним и браузер покажет пользователю не то, что он хотел. Запрещать повторную отсылку запроса только потому, что не пришёл ответ на ещё один на ту же группу данных не есть хорошо. Я не говорю, что проблема нерешаемая — но в TCP такого нет.
Есть более серьёзный проект, в котором зажержки из-за периодического открытия TCP-соединений (сразу скажу — про существование перманентного соединения в HTTP/1.1 я тоже знаю) для AJAX-запросов — это плохо. Поскольку почти во всех браузерах существует способ в некоторых случаях открыть TCP-соединение, мы предпочитаем использовать его, и только в противном случае подключаем AJAX.
Смотря в каких случаях… количество запросов для обоих случаях не изменитсяНе совсем так. Как показывает практика, когда внедряешь для какого-нибудь функционала работу без перезагрузки страницы, им гораздо чаще начинают пользоваться. Иногда на порядок или два. И получается, что время ответа бекенда почти одинаково (напомню, что время рендеринга шаблонов должно быть минимальным в нормальном случае), а число запросов к бекенду сильно возрастает. Я именно это имею ввиду, когда пишу, что в общем случае использование ajax увеличивает нагрузку на бекенд.
К тому же перезагрузка страницы вызывает как минимум проверку на обновление некоторых статических данных — скриптов, картинок, стилейC чего бы, если веб-сервер, их отдающий, обычно сообщает браузеру, что эта информация должна кешироваться и ее не надо каждый раз загружать снова? Зачастую, как раз проблема — обновить закешированную статику в браузере пользователя.
достаточно неплохо владею теорией по сетямЧитая Ваши реплики, склонен считать, что эта фраза означает скорее «я знаю много умных слов из теории сетей».
Вы действительно считаете, что в случае аякс-запроса не используются TCP-сокеты? :))
TCP и AJAX — это разные уровни сетевых технологийНу да, я же написал, что Вы путаете мягкое с кислым. Работа аякса невозможна без использования ТСР-сокетов. Потому что аякс по сути — это ХТТП-запрос к серверу, использующему TCP-сокеты для работы с клиентом. И ему совсем необязательно передавать в одностороннем порядке данные от сервера к клиенту.
не будем забывать, что в AJAX запросы архитектурно асинхронныеНе будем забывать, что JS поддерживает и синхронный обмен запросами. Почему об этом мало кто знает, я не в курсе.
Я не говорю, что проблема нерешаемая — но в TCP такого нетЯ рыдаю под столом, честно. Вы сейчас хотите сказать, что HTTP работает через UDP-сокеты? Блин, ну правда, не отжигайте у всех на виду.
Есть более серьёзный проект, в котором задержки из-за периодического открытия TCP-соединений для AJAX-запросов — это плохо. Нормальный веб-сервер не пробовали использовать?
Поскольку почти во всех браузерах существует способ в некоторых случаях открыть TCP-соединениеНу да, HTTP работает по TCP. Покажите мне хоть один браузер, который не умеет работать с ним :)
мы предпочитаем использовать егоОй, освежите всё же свои знания. Ну правда. У вас така-а-а-я каша в голове…
> Как показывает практика, когда внедряешь для какого-нибудь функционала работу без перезагрузки страницы, им гораздо чаще начинают пользоваться.
Так это же замечательно! В целом аргумент принят.
> Работа аякса невозможна без использования ТСР-сокетов.
Я не идиот, не надо мне это объяснять. То, что вы написали подробно, я написал кратко — это разные уровни. Я иммел в виду, что в JS вы используете более специализированный AJAX (если и сейчас не понято — доставьте наиболее понравившийся синоним синоним «менее абстрактный», «высокоуровневый»), который обладает ограничениями и недостатками, которых лишён TCP.
> Вы сейчас хотите сказать, что HTTP работает через UDP-сокеты?
Где именно я это хочу сказать?
> Нормальный веб-сервер не пробовали использовать?
Пробовали. TCP быстрее. Есть догадки, что тормоза есть в том числе и на стороне браузера — время ожидания в консоли FireBug-а значительно меньше времени генерации ответа сервером. Сниферить не пробовали. Строго говоря, веб-сервер (lighttpd) работает шустро, тормоза у нас создаёт и FCGI-сервер, для которого веб-сервер является клиентом. Конечно, лишняя прослойка скорости не добавляет, но это — дань модульности и универсальности решения.
> Ну да, HTTP работает по TCP.
Хорошо, давайте по пунктам. Протокол TCP обладает большими стандартными возможностями, чем технология AJAX (подробности и оговорки о js.io, comet и пр. см. выше.). Пусть это будет, например, возможность передачи данных сервером без запроса клиентом — удобно, например, для чата или другой передачи данных между пользователями. Если мне из JS-кода доступен AJAX, но не доступен TCP, я не могу считать, что я могу использовать возможности TCP, так как указанная возможность мне не доступна.
Вы же в рассуждениях, видимо, считаете, что возможность использования технологии и возможность её _ограниченного_ использования — это одно и то же.
> Ой, освежите всё же свои знания. Ну правда. У вас така-а-а-я каша в голове…
Было бы весьма неплохо, если бы вы указали на конкретные пробелы в моих знаниях, а то работать старшим разработчиком в области создания серверных компонент как-то тяжеловато, будучи таким недалёким.
Так это же замечательно! В целом аргумент принят.
> Работа аякса невозможна без использования ТСР-сокетов.
Я не идиот, не надо мне это объяснять. То, что вы написали подробно, я написал кратко — это разные уровни. Я иммел в виду, что в JS вы используете более специализированный AJAX (если и сейчас не понято — доставьте наиболее понравившийся синоним синоним «менее абстрактный», «высокоуровневый»), который обладает ограничениями и недостатками, которых лишён TCP.
> Вы сейчас хотите сказать, что HTTP работает через UDP-сокеты?
Где именно я это хочу сказать?
> Нормальный веб-сервер не пробовали использовать?
Пробовали. TCP быстрее. Есть догадки, что тормоза есть в том числе и на стороне браузера — время ожидания в консоли FireBug-а значительно меньше времени генерации ответа сервером. Сниферить не пробовали. Строго говоря, веб-сервер (lighttpd) работает шустро, тормоза у нас создаёт и FCGI-сервер, для которого веб-сервер является клиентом. Конечно, лишняя прослойка скорости не добавляет, но это — дань модульности и универсальности решения.
> Ну да, HTTP работает по TCP.
Хорошо, давайте по пунктам. Протокол TCP обладает большими стандартными возможностями, чем технология AJAX (подробности и оговорки о js.io, comet и пр. см. выше.). Пусть это будет, например, возможность передачи данных сервером без запроса клиентом — удобно, например, для чата или другой передачи данных между пользователями. Если мне из JS-кода доступен AJAX, но не доступен TCP, я не могу считать, что я могу использовать возможности TCP, так как указанная возможность мне не доступна.
Вы же в рассуждениях, видимо, считаете, что возможность использования технологии и возможность её _ограниченного_ использования — это одно и то же.
> Ой, освежите всё же свои знания. Ну правда. У вас така-а-а-я каша в голове…
Было бы весьма неплохо, если бы вы указали на конкретные пробелы в моих знаниях, а то работать старшим разработчиком в области создания серверных компонент как-то тяжеловато, будучи таким недалёким.
… он сказал «Поехали» и махнул рукой…
Вы опять мешаете в кучу разные вещи. Фактически, пишете «Камаз обладает ограничениями и недостатками, которых лишен двигатель внутреннего сгорания». Так понятнее, почему Вас забавно читать?
На AJAX накладываются ограничения HTTP-протокола, который по историческим причинам разрабатывали именно с существующими ограничениями. Хотя я слабо представляю веб-приложение на основе браузера, где это было бы критично. Просветите, пожалуйста. Мне, правда, очень интересно.
Вот здесь:
«AJAX запросы архитектурно асинхронные, это означает возможное несовпадение порядка запросов и ответов от сервера… в TCP такого нет»
Действительно, TCP гарантирует, что пакеты соберутся в нужном порядке. В отличие от UDP, который этого не гарантирует, как не гарантирует доставку вообще. Логично предположить, что если Вы пишете, про несовпадение порядка запросов и противопоставляете ajax работе с tcp-сокетом («мы используем… TCP-сокет… вместо AJAX-запросов»), то легко можете иметь ввиду, что AJAX — суть надстройка над UDP, а не над TCP.
Блин, ну вот опять Вы жжоте. Не может быть TCP быстрее TCP. Может быть, что самописное-приложение-сервер, обслуживающее несколько десятков соединений напрямую, быстрее по каким-то причинам, чем стандартное-приложение-веб-сервер, обслуживающие пул из нескольких сотен или тысяч соединений. Хотя это кажется крайне сомнительным, с учетом современных методов мультиплексирования. И если у вас там в приложении еще и FastCGI, то вообще крайне сомнительно, что нечто самописное Вам так сильно поможет. Как бы Вы хитро не обращались к сокетам.
Хорошо. Пока у меня сложилось представление, что Вы слабо разбираетесь в нюансах протоколов TCP и HTTP, слабо понимаете как реализована AJAX-технология и не имеете достаточного опыта в работе с высокими нагрузками и различными веб-серверами. Мне давать ссылки на конкретную документацию или найдете сами?
AJAX… обладает ограничениями и недостатками, которых лишён TCP
Вы опять мешаете в кучу разные вещи. Фактически, пишете «Камаз обладает ограничениями и недостатками, которых лишен двигатель внутреннего сгорания». Так понятнее, почему Вас забавно читать?
На AJAX накладываются ограничения HTTP-протокола, который по историческим причинам разрабатывали именно с существующими ограничениями. Хотя я слабо представляю веб-приложение на основе браузера, где это было бы критично. Просветите, пожалуйста. Мне, правда, очень интересно.
Где именно я это хочу сказать?
Вот здесь:
«AJAX запросы архитектурно асинхронные, это означает возможное несовпадение порядка запросов и ответов от сервера… в TCP такого нет»
Действительно, TCP гарантирует, что пакеты соберутся в нужном порядке. В отличие от UDP, который этого не гарантирует, как не гарантирует доставку вообще. Логично предположить, что если Вы пишете, про несовпадение порядка запросов и противопоставляете ajax работе с tcp-сокетом («мы используем… TCP-сокет… вместо AJAX-запросов»), то легко можете иметь ввиду, что AJAX — суть надстройка над UDP, а не над TCP.
TCP быстрее.
Блин, ну вот опять Вы жжоте. Не может быть TCP быстрее TCP. Может быть, что самописное-приложение-сервер, обслуживающее несколько десятков соединений напрямую, быстрее по каким-то причинам, чем стандартное-приложение-веб-сервер, обслуживающие пул из нескольких сотен или тысяч соединений. Хотя это кажется крайне сомнительным, с учетом современных методов мультиплексирования. И если у вас там в приложении еще и FastCGI, то вообще крайне сомнительно, что нечто самописное Вам так сильно поможет. Как бы Вы хитро не обращались к сокетам.
то — дань модульности и универсальности решенияЭта фраза характеризует вашу систему с нелучшей стороны. Я действительно начинаю убеждаться, что дело не в AJAX. А как обычно.
Возможность передачи данных сервером без запроса клиентом — удобно… для чата или другой передачи данных между пользователямиУуу, как всё запущено. Вы о тройном рукопожатии что-нибудь слышали? TCP не возможен без установки соединения, которое инициализируется клиентом. Клиент всегда есть. И сервер тоже. Только они могут местами меняться. Похоже, пора давать ссылки на RFC. Я не люблю тыкать в мануал незнакомых людей, но Вы всячески к этому меня подводите. У меня сложилось впечатление, что Вы явно знаете о многих кусочках теории работы сетей, но цельной картины у Вас в голове нет.
Вы же в рассуждениях, видимо, считаете, что возможность использования технологии и возможность её _ограниченного_ использования — это одно и то же.Не приписывайте мне то, о чем я не говорил. Я лишь пытаюсь донести до Вас, что Вы или не представляете до конца, о чём пытаетесь спорить, или не можете это нормально выразить словами. Или и то, и то.
Было бы весьма неплохо, если бы вы указали на конкретные пробелы в моих знаниях
Хорошо. Пока у меня сложилось представление, что Вы слабо разбираетесь в нюансах протоколов TCP и HTTP, слабо понимаете как реализована AJAX-технология и не имеете достаточного опыта в работе с высокими нагрузками и различными веб-серверами. Мне давать ссылки на конкретную документацию или найдете сами?
работать старшим разработчиком в области создания серверных компонент как-то тяжеловато, будучи таким недалёким.Я уже смирился, что мир несовершенен, и многие люди занимают должности, не имея на то достаточной квалификации.
> Фактически, пишете «Камаз обладает ограничениями и недостатками, которых лишен двигатель внутреннего сгорания».
Камаз не является специализацией технологии генерации крутящего момента. Правильная аналогия была бы «Двигатель камаза обладает ограничениями и недостатками, которых лишён двигатель внутреннего сгорания в общем случае».
Если аналог двигателя — технология взаимодействия, то аналогией камазу в данном случае является приложение.
Для разработчика JS-кода, взаимодействующего с сервером, совершенно неважно, что AJAX использует TCP при передаче данных, и что первое — технология, использующая протокол прикладного уровня, а второе — протокол транспортного уровня, для него и то, и другое — технология взаимодействия с сервером, но с разными возможностями.
Конечно, для разработчика браузера аналогия может быть другой, но мы ведь не об этом говорим.
> Логично предположить, что если Вы пишете, про несовпадение порядка запросов…
AJAX-запросы могут уйти по разным TCP-каналам и обработаны с разной скоростью. Поэтому AJAX не гарантирует порядка запросов и ответов. Пример с меню я уже приводил, если вы не поняли его, вот подробности:
1. Клиент посылает AJAX-запрос A, он уходит в один TCP-канал.
2. Клиент не ждёт ответа от сервера и посылает AJAX-запрос B, он уходит в другой TCP-канал.
3. Сервер тоже асинхронный, о логическом порядке запросов из разных каналов он ничего не знает, он обработал запрос из второго TCP-канала раньше и вернул ответ клиенту.
4. На клиенте запустился обработчик ответа на запрос B.
У нас, если это необходимо, сервер осведомлён о логическом порядке запросов, и ответы клиентом обрабатываются в том же порядке, что и запросы, но это из коробки не идёт. Это сделано, например, для операций модификаций данных на сервере, чувствительных к порядку их применения.
>> TCP быстрее
> Не может быть TCP быстрее TCP.
Я не сравниваю TCP и TCP, я сравниваю TCP и AJAX, причём тормоза всего в комплексе, начиная от генерации запроса клиентом, заканчивая получением ответа от сервера. У нас TCP общается напрямую с сервером приложений. Без возможности установить TCP-соединение из кода нашего приложения на стороне клиента, используется несколько прослоек, включая AJAX с его торомозной реализацией в браузерах, web-сервер и FastCGI-сервер.
>> FCGI… — дань модульности и универсальности решения
> Эта фраза характеризует вашу систему с нелучшей стороны.
Почему? FCGI-стандартная, мощная технология, в том числе и взаимодействия веб-сервера с приложениями. Я могу легко подключить несколько приложений к серверу, причём как локальных, так и расположенных на других серверах. При этом неважно, с помощью каких технологий приложения реализованы, ибо протокол взаимодействия — стандартный. Аналогичо и веб-сервера можно поменять при желании, единственное требование — поддержка ими FastCGI.
Теперь снова Ваш ход — чем это характеризует систему с нелучшей стороны?
> Ууу, как всё запущено. Вы о тройном рукопожатии что-нибудь слышали?
Разумеется. И о всём, что вы мне рассказали в процессе диалога, тоже.
>> Возможность передачи данных сервером без запроса клиентом.
> TCP не возможен без установки соединения, которое инициализируется клиентом.
А я и не говорил ничего противоречащего. Я говорил про обмен данными по соединению, а не про его установку. Чтож, давайте и здесь напишу подробней. Надеюсь, про изредка работающие исключения вроде orbited, comet и т.д. мне в третий раз упоминать не нужно?
Итак:
Ну, пусть для простоты будет чат. Клиенты A и B соединяются с сервером по TCP. Клиент A отправляет серверу сообщение, сервер его получает по сокету с A и тут же (опять же, с очевидными оговорками вроде «если есть свободный участок нужного размера в TCP-окне», «если нет очереди других пакетов». «если передающая среда свободна») кладёт в нужный буфер и ядро скоренько отправляет его в сеть клиенту B, а клиент B доволно быстро его получает и отображает.
Это — передача данных сервера? Да.
Клиент B получил сообщения от A, не запрашивая его от сервера? Да.
Значит, это — передача данных сервером без запроса клиента.
> Ууу, как всё запущено. Вы о тройном рукопожатии что-нибудь слышали?
А вы как думаете?
> Я не люблю тыкать в мануал незнакомых людей, но Вы всячески к этому меня подводите.
Пожалуйста, я могу чего-то не знать или ошибаться, но, ещё раз — где у меня пробелы в знаниях в контексте нашего спора?
> Не приписывайте мне то, о чем я не говорил.
Вы не говорили, но, возможно, так считаете. Вы говорили, что, имея возможность используя AJAX, я могу использовать TCP. Я говорил, что не считаю, что могу использовать TCP, если мне доступны лишь весьма ограниченные его возможности в случае использования AJAX. Всё правильно?
> Пока у меня сложилось представление, что Вы слабо разбираетесь в нюансах протоколов TCP и HTTP
А конкретней?
> слабо понимаете как реализована AJAX-технология
На стороне клиента — да, слабо. Но где ошибки в моих рассуждениях в нашем споре?
> и не имеете достаточного опыта в работе с высокими нагрузками
Есть лишь минимальный, но не думаю, что я исказил факты из-за этого. Темы тормозов _из-за высокой нагрузки на сервер_ мы в нашем обсуждании не касались.
> и различными веб-серверами
Пробовал несколько. Один простейший, специализированный, писал сам.
> Я уже смирился, что мир несовершенен, и многие люди занимают должности, не имея на то достаточной квалификации.
В отношении меня вы это пока не обосновали.
Камаз не является специализацией технологии генерации крутящего момента. Правильная аналогия была бы «Двигатель камаза обладает ограничениями и недостатками, которых лишён двигатель внутреннего сгорания в общем случае».
Если аналог двигателя — технология взаимодействия, то аналогией камазу в данном случае является приложение.
Для разработчика JS-кода, взаимодействующего с сервером, совершенно неважно, что AJAX использует TCP при передаче данных, и что первое — технология, использующая протокол прикладного уровня, а второе — протокол транспортного уровня, для него и то, и другое — технология взаимодействия с сервером, но с разными возможностями.
Конечно, для разработчика браузера аналогия может быть другой, но мы ведь не об этом говорим.
> Логично предположить, что если Вы пишете, про несовпадение порядка запросов…
AJAX-запросы могут уйти по разным TCP-каналам и обработаны с разной скоростью. Поэтому AJAX не гарантирует порядка запросов и ответов. Пример с меню я уже приводил, если вы не поняли его, вот подробности:
1. Клиент посылает AJAX-запрос A, он уходит в один TCP-канал.
2. Клиент не ждёт ответа от сервера и посылает AJAX-запрос B, он уходит в другой TCP-канал.
3. Сервер тоже асинхронный, о логическом порядке запросов из разных каналов он ничего не знает, он обработал запрос из второго TCP-канала раньше и вернул ответ клиенту.
4. На клиенте запустился обработчик ответа на запрос B.
У нас, если это необходимо, сервер осведомлён о логическом порядке запросов, и ответы клиентом обрабатываются в том же порядке, что и запросы, но это из коробки не идёт. Это сделано, например, для операций модификаций данных на сервере, чувствительных к порядку их применения.
>> TCP быстрее
> Не может быть TCP быстрее TCP.
Я не сравниваю TCP и TCP, я сравниваю TCP и AJAX, причём тормоза всего в комплексе, начиная от генерации запроса клиентом, заканчивая получением ответа от сервера. У нас TCP общается напрямую с сервером приложений. Без возможности установить TCP-соединение из кода нашего приложения на стороне клиента, используется несколько прослоек, включая AJAX с его торомозной реализацией в браузерах, web-сервер и FastCGI-сервер.
>> FCGI… — дань модульности и универсальности решения
> Эта фраза характеризует вашу систему с нелучшей стороны.
Почему? FCGI-стандартная, мощная технология, в том числе и взаимодействия веб-сервера с приложениями. Я могу легко подключить несколько приложений к серверу, причём как локальных, так и расположенных на других серверах. При этом неважно, с помощью каких технологий приложения реализованы, ибо протокол взаимодействия — стандартный. Аналогичо и веб-сервера можно поменять при желании, единственное требование — поддержка ими FastCGI.
Теперь снова Ваш ход — чем это характеризует систему с нелучшей стороны?
> Ууу, как всё запущено. Вы о тройном рукопожатии что-нибудь слышали?
Разумеется. И о всём, что вы мне рассказали в процессе диалога, тоже.
>> Возможность передачи данных сервером без запроса клиентом.
> TCP не возможен без установки соединения, которое инициализируется клиентом.
А я и не говорил ничего противоречащего. Я говорил про обмен данными по соединению, а не про его установку. Чтож, давайте и здесь напишу подробней. Надеюсь, про изредка работающие исключения вроде orbited, comet и т.д. мне в третий раз упоминать не нужно?
Итак:
Ну, пусть для простоты будет чат. Клиенты A и B соединяются с сервером по TCP. Клиент A отправляет серверу сообщение, сервер его получает по сокету с A и тут же (опять же, с очевидными оговорками вроде «если есть свободный участок нужного размера в TCP-окне», «если нет очереди других пакетов». «если передающая среда свободна») кладёт в нужный буфер и ядро скоренько отправляет его в сеть клиенту B, а клиент B доволно быстро его получает и отображает.
Это — передача данных сервера? Да.
Клиент B получил сообщения от A, не запрашивая его от сервера? Да.
Значит, это — передача данных сервером без запроса клиента.
> Ууу, как всё запущено. Вы о тройном рукопожатии что-нибудь слышали?
А вы как думаете?
> Я не люблю тыкать в мануал незнакомых людей, но Вы всячески к этому меня подводите.
Пожалуйста, я могу чего-то не знать или ошибаться, но, ещё раз — где у меня пробелы в знаниях в контексте нашего спора?
> Не приписывайте мне то, о чем я не говорил.
Вы не говорили, но, возможно, так считаете. Вы говорили, что, имея возможность используя AJAX, я могу использовать TCP. Я говорил, что не считаю, что могу использовать TCP, если мне доступны лишь весьма ограниченные его возможности в случае использования AJAX. Всё правильно?
> Пока у меня сложилось представление, что Вы слабо разбираетесь в нюансах протоколов TCP и HTTP
А конкретней?
> слабо понимаете как реализована AJAX-технология
На стороне клиента — да, слабо. Но где ошибки в моих рассуждениях в нашем споре?
> и не имеете достаточного опыта в работе с высокими нагрузками
Есть лишь минимальный, но не думаю, что я исказил факты из-за этого. Темы тормозов _из-за высокой нагрузки на сервер_ мы в нашем обсуждании не касались.
> и различными веб-серверами
Пробовал несколько. Один простейший, специализированный, писал сам.
> Я уже смирился, что мир несовершенен, и многие люди занимают должности, не имея на то достаточной квалификации.
В отношении меня вы это пока не обосновали.
Камаз не является специализацией технологии генерации крутящего момента
Именно. Так же как AJAX не является транспортным протоколом. Но в предыдущих сообщениях Вы неоднократно писали фразы, которые именно это и подразумевали своим некорректным сравнением мягкого с кислым. Учитесь правильно формулировать свои мысли.
Я не сравниваю TCP и TCPДа сравниваете, сравниваете. Вы ж прямо написали, что TCP быстрее, чем ответы от веб-сервера. Но при этом не сказали, что подразумеваете, что TCP соединение с Вашим сервером уже установлено, а в случае использования Вами AJAX оно фактически устанавливается каждый раз заново. Иначе собственно непонятно за счет чего быстрота. И так, и так браузеру придется соединиться с TCP-сокетом сервера. Веб-сервер это или же ваш демон — какая разница? Накладные расходы на вызов XMLHttpRequest не дадут существенного увеличения времени установки TCP-соединения.
Поэтому AJAX не гарантирует порядка запросов и ответовГм. Не совсем так. Я не зря упоминал про синхронные запросы в JS. Другое дело, что текущие реализации XHR, насколько мне известно, не поддерживают полноценный pipelining, а поддержка браузером persistent connection с сервером зависят больше от принимающего сервера, нежели от умения XHR отправлять заголовок Keep-Alive. Ну то есть, определенный смысл в Ваших действиях есть, но вопрос невозможности отказаться от прямого соединения (Java, кстати, или Flash?) в пользу дееспособной конфигурации веб-сервера остается открытым.
Теперь снова Ваш ход — чем это характеризует систему с нелучшей стороны?Пальцем в небо. Я писал не про FastCGI, посмотрите внимательно на цитату, которую я там выделил.
А я и не говорил ничего противоречащего. Я говорил про обмен данными по соединению, а не про его установку.А ну надо же. Оказывается, у нас уже что-то там с чем-то соединено, и сервер просто использует это соединение. Ну-ка ткните-ка меня в цитатку из предыдущих сообщений, где Вы говорили, что соединение состоялось. Без этой цитаты из Ваших фраз следует как раз то, о чем я писал выше — в предыдущих комментариях Вы фактически говорите, что инициатором передачи файла клиенту является сервер. Что полностью противоречит принципам TCP. Учитесь правильно формулировать свои мысли.
Вы говорили, что, имея возможность используя AJAX, я могу использовать TCP.Не говорил. Не путайте причину и следствие. Я говорил, что AJAX в принципе невозможен без TCP: «Работа аякса невозможна без использования ТСР-сокетов». Про то, что AJAX предоставляет все возможности TCP я не упоминал. Цитату в студию, если таки упоминал.
А конкретней?
Расслабьтесь. После Вашего последнего поста стало очевидно, что Вы просто не умеете правильно формулировать свои мысли, чтобы собеседнику не пришлось домысливать за Вас вещи, которые следуют из Ваших фраз, но как оказалось, которые Вы совсем не имели в виду. Перечитайте. И попробуйте представить наиболее очевидные вещи, которые следуют из Ваших фраз без полных формулировок, с многочисленными допущениями и умолчаниями с Вашей стороны. И поймете, что очень часто Ваши фразы — полная ахинея с точки зрения действительного положения вещей.
Эт не сугубо мое мнение, данную беседу читало уже много людей, разбирающихся в сетях, и у всех одно мнение — у Вас каша в голове. А похоже, все проблемы — от неправильного выражения мыслей или излишней торопливости при их переносе в текст. В общем, учитесь правильно формулировать свои мысли. Из-за того, что они у Вас скачут с пятого на десятое; из-за того, что Вы многое пропускаете, считая, что мысли собеседника пойдут ровно так же как и Ваши и обязательно поймут что Вы недосказали, получается, что Вы мешаете в кучу разные понятия и это сразу цепляет взгляд знающего человека.
Темы тормозов _из-за высокой нагрузки на сервер_ мы в нашем обсуждании не касались.И всё-таки у меня стойкая мысль, что проблемы производительности Вашего продукта — не в AJAX'е. Тут нужно глубже копать, у меня нет достаточной информации. Но интуиция пока утверждает, что Ваших костылей можно было бы избежать. Но эт уже отдельный разговор.
В отношении меня вы это пока не обосновалиСчитайте, что под недостаточной квалификацией я имел в виду, что Вы не умеете полно и точно излагать свои мысли. Вам повезло, что я терпелив и подвел Вас к точной формулировке того, что Вы имели в виду в предыдущих постах ;)
>> Попробуйте выключить JavaScript — меню будет работать.
>> Попробуй выключить CSS — сайт работает.
А если выключить монитор?
>> Попробуй выключить CSS — сайт работает.
А если выключить монитор?
почему, когда я захожу на сайт — КРУПНЫЙ САЙТ, заполняю кучу полей, и жму кнопу Отправить — ничего не происходит? нету никаких сообщений, что у меня отключены скрипты и я могу нихера не тратить свое время, все равно при обновлении страницы после включения скриптов все мои труды и поӕмы пропадут в небытие? я не люблю видеть на сайтах, на который я зайду один раз, какой то интерактив, флешки, прыгающие на ебанутом жаваквери картинки! и я отключаю ӕто все просто.
я постоянно на этом сайте, мне нравится его интерактив — я включу ему скрипты и все спокойно. а прыгать по интернету на тысяче сайтов и везде смотреть как разработчики по ӕффектам соревнуются с собой не по мне. сайт должен быть доступен в любом случае, все его функции. а что 1% без скриптов… да хоть 0.1. сайт ты делаешь не для себя.
я постоянно на этом сайте, мне нравится его интерактив — я включу ему скрипты и все спокойно. а прыгать по интернету на тысяче сайтов и везде смотреть как разработчики по ӕффектам соревнуются с собой не по мне. сайт должен быть доступен в любом случае, все его функции. а что 1% без скриптов… да хоть 0.1. сайт ты делаешь не для себя.
Полностью согласен.
сайт должен быть доступен в любом случае, все его функцииНет. Большинство функций — да. Все — нет.
Есть функции, которые ненавязчиво снижают уровень информационного шума (читай «спама») на проекте. И если они отсекают большую часть ботов (а использование JS для форм действительно отсекает большинство ботов на текущий момент времени), мне будет реально пофиг, что они отсекут 0.6% пользователей-параноиков, которые отключают JS и не могут написать сообщение. Хотя таких я предупрежу, что JS надо включить. Или дам капчу.
Увы, но делая сайты с миллионной посещаемостью, достаточно быстро понимаешь, что всех пользователей всё равно никогда не удовлетворить и какой-то процент так и так уйдет обиженным. Другое дело, что можно стараться минимизировать этот процент. Носкрипт — как раз попытка его минимизировать.
Это суровая реальность, как бы Вы к этому не относились.
Это суровая реальность, как бы Вы к этому не относились.
никто не мешает пользователям без JS показывать капчу)
UFO just landed and posted this here
10 кнопок, input type=«image» с разными value. все кнопки — прозрачные gif, кроме одной :-)
Все самое лучшее — это самое простое.
Простая картинка с циферками…
Простая картинка с циферками…
Давно уже обходят… с помощью дешёвой рабочей силы. 1000 капч стоят 1$
Причём данный подход может потенциально обойти практически любую защиту
Можно ссылочку? (я не подработать, просто интересно)
(:
(:
Вот один из таких сайтов: www.kolotibablo.com
а с чего Вы взяли что они представленную в статье защиту не обойдут?
Часто ипользую браузер links, там нет графики. Как мне быть?
Использовать браузер 21го века =)
Хорошо, возьмём eLinks. ELinks is a feature-rich program for browsing the web in text mode. 21го века, текстовый.
Скажите, а это удобно? ИМХО не понимаю я как можно работать просто с текстом =)
Удобно, особенно когда через гпрс на мобиле гугл по три минуты грузится
1. В eLinks удобная навигация с клавиатуры — основого инструмента ввода данных в программисткой среде:
Нажимаешь точку, слева от всех ссылок и полей ввода появляются числа, набираешь число, нажимаешь Enter. Очень удобно. Не хуже, чем в konqueror.
2. Это быстро.
2а) Быстро при медленном инете. Представьте канал до сервера — 1000 CPS, канал от сервера — большой. Канал сервера во внешний мир — широкий. Запускаем eLinks, наслаждаемся жизнью. Однажды, специально для одного дебильного сайта, использующего картинки-капчи, мне пришлось ставить X-сервер, icewm, firefox, но скорость отрисовки экрана и реакции на мышку через VNC — минуты две. Собственно, снёс нафиг и вернулся в eLinks.
2б) Быстро на медленной машине. Есть старые машины, они крутой графический браузер не потянут. На моей домашней, например, firefox тормозит безбожно — 10 секунд на открытие вкладки — это перебор. Konqueror работает приемлимо, а eLinks просто летает.
3. Это возможно без графики. Графика есть не везде и не всегда. Когда у меня упал X-сервер из-за кривого драйвера от nvidia и я не смог вернуть всё назад руками — как вы думаете, каким браузером я воспользовался для поиска решения проблемы в гугле? Каким браузером пользуется наш сисадмин, когда поднимает сервера с консоли?
Нажимаешь точку, слева от всех ссылок и полей ввода появляются числа, набираешь число, нажимаешь Enter. Очень удобно. Не хуже, чем в konqueror.
2. Это быстро.
2а) Быстро при медленном инете. Представьте канал до сервера — 1000 CPS, канал от сервера — большой. Канал сервера во внешний мир — широкий. Запускаем eLinks, наслаждаемся жизнью. Однажды, специально для одного дебильного сайта, использующего картинки-капчи, мне пришлось ставить X-сервер, icewm, firefox, но скорость отрисовки экрана и реакции на мышку через VNC — минуты две. Собственно, снёс нафиг и вернулся в eLinks.
2б) Быстро на медленной машине. Есть старые машины, они крутой графический браузер не потянут. На моей домашней, например, firefox тормозит безбожно — 10 секунд на открытие вкладки — это перебор. Konqueror работает приемлимо, а eLinks просто летает.
3. Это возможно без графики. Графика есть не везде и не всегда. Когда у меня упал X-сервер из-за кривого драйвера от nvidia и я не смог вернуть всё назад руками — как вы думаете, каким браузером я воспользовался для поиска решения проблемы в гугле? Каким браузером пользуется наш сисадмин, когда поднимает сервера с консоли?
Когда сисадмин поднимает сервера в консоли, он не будет сидеть вконтакте. Если он вменяемый, конечно.
У меня тоже сервера есть, без графической среды вообще. И там есть линкс. Но единственное, для чего он там используется — это проверка доступности двух-трех сайтов. Причем дальше главной страницы как правило уходить не приходится. Причем сайты эти мои же, поэтому на каждом из них есть специальная тестовая страница, которая сообщает «это работает, это работает, а вот это упало». И все.
И не полезу я этим линксом ни вконтакт, ни на хабру, ни в гугл. Для этого у меня есть человеческая машина с человеческим браузером.
Зачем придумывать эти сферические примеры в вакууме, если их все равно все проигнорируют?
У меня тоже сервера есть, без графической среды вообще. И там есть линкс. Но единственное, для чего он там используется — это проверка доступности двух-трех сайтов. Причем дальше главной страницы как правило уходить не приходится. Причем сайты эти мои же, поэтому на каждом из них есть специальная тестовая страница, которая сообщает «это работает, это работает, а вот это упало». И все.
И не полезу я этим линксом ни вконтакт, ни на хабру, ни в гугл. Для этого у меня есть человеческая машина с человеческим браузером.
Зачем придумывать эти сферические примеры в вакууме, если их все равно все проигнорируют?
Значит сайт потеряет одного посетителя маргинала. Может это и к лучшему.
Почему маргинала? Я все причины подробно расписал. Обоснуйте свою позицию.
1. Ну так и воспользуйтес konqueror, в Opere по-моему это тоже есть, для FF есть необходимые плагины
2. a) При медленном инете обычные люди отключают картинки, js тут не при чем
2. б) Иногда надо обновлять компьютер. Сейчас даже самый раздешевый новый комп который можно найти вполне быстро серфит по интернетам
3. Странно, но мне казалось что проблема с линуками, у которых «упал x-сервер из-за кривого драйвера nvidia» осталась году этак в 2003. Обновите в конце-концов софт и возможно железо, не мучайте себя. Сисадмин обычно поднимает сервер без использования броузера.
Итого: У вас древний комп, удивительно медленный инет, и странно глючный набор софта.
Вы еще считаете себя не маргиналом?
Все конечно зависит от направленности сайта, но проблема спама обычно появляется на форумах и блогах, так называемое развлекательное направление. Посмотрите статистику средне-статистического развлекательного сайта по использованию броузеров, даже если вы найдете там броузер links/elinks — там скорее всего будет стоять 1 — это вы.
2. a) При медленном инете обычные люди отключают картинки, js тут не при чем
2. б) Иногда надо обновлять компьютер. Сейчас даже самый раздешевый новый комп который можно найти вполне быстро серфит по интернетам
3. Странно, но мне казалось что проблема с линуками, у которых «упал x-сервер из-за кривого драйвера nvidia» осталась году этак в 2003. Обновите в конце-концов софт и возможно железо, не мучайте себя. Сисадмин обычно поднимает сервер без использования броузера.
Итого: У вас древний комп, удивительно медленный инет, и странно глючный набор софта.
Вы еще считаете себя не маргиналом?
Все конечно зависит от направленности сайта, но проблема спама обычно появляется на форумах и блогах, так называемое развлекательное направление. Посмотрите статистику средне-статистического развлекательного сайта по использованию броузеров, даже если вы найдете там броузер links/elinks — там скорее всего будет стоять 1 — это вы.
Ой, и еще не заметил — вы предлагаете использовать удаленный X-сервер через медленный инет как среду для запуска графического броузера. Ну да, все обычно так и делают. Поставить на сервере прокси не наш метод!
1. Хорошие плагины для FF не нашёл, да он и тормозной очень. Opera отсутствует в репозиториях моего дистрибутива, левые пакеты не люблю ставить без надобности. Но в целом принято, эта проблема решается.
2. а) Хорошо, возьмём этот пост без картинок и JS.
$ wget habrahabr.ru/blogs/webdev/50328/ --output-document=/tmp/11; wc -c /tmp/11
340015 /tmp/11
$ links -dump habrahabr.ru/blogs/webdev/50328/|wc -c
94826
$ links -dump habrahabr.ru/blogs/webdev/50328/|gzip|wc -c
24030
Разница — в 3.5 раза. А по SSH трафик ещё всегда сжиматься может, здесь так вообще разница в 12 раз получается… Скорость GRPS в моём регионе — около килобайта-двух в секунду. Скорость инета через локалку в моей домашней сети по последним официальным данным — 2 килобайта в секунду на коннект, 5 — всего. Нас в сети — несколько тысяч.
2. б) Пардон, но не у меня одного на обновление компа нет средств. Вот неделю назад только 486-е списали, а Pentium-III / 128 Mb RAM ещё пашут, в том числе и на серверах. Вы мне за свои деньги предлагаете туда рабочий комп купить? Да, я ещё и в коммерческой организации работаю — здесь, конечно, железо современное. Но в коммерческой нас — 40, а там — ~3000.
3. Обновляюсь регулярно, из-за чего и падает. Вот вчера после обновления драйвер nvidia насильно выставил X-серверу такой маленький DPI, что работать в графике до правки конфигов было, мягко говоря, тяжело. В каком из действий моя ошибка? Это не я кривой, это софт кривой, причём тот, который проприетарный.
Сисадмин наш, видимо, об этом не знал, когда сидел в «серверной» после kernel panic'а. И в процессе переезда, когда в помещении ничего, кроме серверов и сетевого оборудования в здании не было. В целом, в связи с последним вашим абзацем, возражение по третьему пункту принято — серьёзные ресурсы вроде google не позволят себе потерять пользователей из соображений экономии, а развлекательный портал при настройке сервера админу не пригодится.
По поводу вашего последнего предложения прошу прочитать сей коммент — habrahabr.ru/blogs/webdev/50328/?reply_to=1321993#comment_1321714
«Маргина́л, маргина́льный челове́к (от лат. margo — край) — человек, живущий вне общества по теории профессора Павла Филиппчука.»
Наконец — нет, маргиналом не считаю. В пунктах 2а и 2б я рассказал, почему я такой не один. Мой выбор обусловлен обстоятельствоми нахождения не-в-столице, а не «утверждением своей собственной системой норм и ценностей».
2. а) Хорошо, возьмём этот пост без картинок и JS.
$ wget habrahabr.ru/blogs/webdev/50328/ --output-document=/tmp/11; wc -c /tmp/11
340015 /tmp/11
$ links -dump habrahabr.ru/blogs/webdev/50328/|wc -c
94826
$ links -dump habrahabr.ru/blogs/webdev/50328/|gzip|wc -c
24030
Разница — в 3.5 раза. А по SSH трафик ещё всегда сжиматься может, здесь так вообще разница в 12 раз получается… Скорость GRPS в моём регионе — около килобайта-двух в секунду. Скорость инета через локалку в моей домашней сети по последним официальным данным — 2 килобайта в секунду на коннект, 5 — всего. Нас в сети — несколько тысяч.
2. б) Пардон, но не у меня одного на обновление компа нет средств. Вот неделю назад только 486-е списали, а Pentium-III / 128 Mb RAM ещё пашут, в том числе и на серверах. Вы мне за свои деньги предлагаете туда рабочий комп купить? Да, я ещё и в коммерческой организации работаю — здесь, конечно, железо современное. Но в коммерческой нас — 40, а там — ~3000.
3. Обновляюсь регулярно, из-за чего и падает. Вот вчера после обновления драйвер nvidia насильно выставил X-серверу такой маленький DPI, что работать в графике до правки конфигов было, мягко говоря, тяжело. В каком из действий моя ошибка? Это не я кривой, это софт кривой, причём тот, который проприетарный.
Сисадмин наш, видимо, об этом не знал, когда сидел в «серверной» после kernel panic'а. И в процессе переезда, когда в помещении ничего, кроме серверов и сетевого оборудования в здании не было. В целом, в связи с последним вашим абзацем, возражение по третьему пункту принято — серьёзные ресурсы вроде google не позволят себе потерять пользователей из соображений экономии, а развлекательный портал при настройке сервера админу не пригодится.
По поводу вашего последнего предложения прошу прочитать сей коммент — habrahabr.ru/blogs/webdev/50328/?reply_to=1321993#comment_1321714
«Маргина́л, маргина́льный челове́к (от лат. margo — край) — человек, живущий вне общества по теории профессора Павла Филиппчука.»
Наконец — нет, маргиналом не считаю. В пунктах 2а и 2б я рассказал, почему я такой не один. Мой выбор обусловлен обстоятельствоми нахождения не-в-столице, а не «утверждением своей собственной системой норм и ценностей».
Я честно признаюсь, такую удручающую ситуацию вижу впервые, но согласитесь, что владельцы сайта тоже вряд ли будут печься о пользователях, которые не могут просмотреть рекламу на сайте, которая является их основным доходом.
Да и случай ваш крайне редкий, чтобы сайт целиком под вас подстраивать, для пользователей с отключенным js покажут капчу, вот и выбирайте, что лучше. Ведь это не повод спамеров на сайт запускать.
А большинство людей защиту, которая реализована стредствами js даже не увидит, что является несомненным плюсом в юзабилити. С этим, по-моему нельзя не согласиться.
Да и случай ваш крайне редкий, чтобы сайт целиком под вас подстраивать, для пользователей с отключенным js покажут капчу, вот и выбирайте, что лучше. Ведь это не повод спамеров на сайт запускать.
А большинство людей защиту, которая реализована стредствами js даже не увидит, что является несомненным плюсом в юзабилити. С этим, по-моему нельзя не согласиться.
Может у конторы потому и денег на обновления парка железа нету, что все 3000 занимаются настройкой удалённого ИксСервера для того, чтобы потом инетится через линкс, вместо того, чтобы работать?
Контора государственная, денги у конторы есть — недавно вот грант на 850 миллионов рублей выиграли. Только деньги оседают, скажем так, не во всех кругах. Так что проявлений их не видно ни в железе, ни в зарплате (которая, кстати, ниже прожиточного миннимума), ни, тем более, в широте интернет-канала. Но особенности распределения финансирования в государственных учреждениях, полагаю, выходят далеко за рамки темы данного обсуждения.
Ну значит конторе просто не нужен (современный) Интернет. Если вам нужен — купите себе ноут или коммуникатор.
За рамки обсуждения так же выходит нытьё про «плохой интернет» и «старое железо».
За рамки обсуждения так же выходит нытьё про «плохой интернет» и «старое железо».
Вы искажаете факты. У меня есть и ноут, и КПК, и мощная машина, и современный интернет на другой работе, и я не ныл. Я объяснял причины, почему бывает удобно использовать eLinks, а интернет и старое железо — это фактические подтверждения моим аргументам.
Интернет-технологии развиваются. Это факт. Там, где интернет нужен — есть технические средства в актуальном, для потребления интернета, состоянии. Это тоже факт. Должна быть возможность пользоваться интернетом с радиолы, выпущенной в СССР. Это фейк. Я написал браузер, который загружает и отображает только половину букв, потому, что это эконмит траффик (и как факт может возникнуть мифическая ситуация, когда это удобно), и веб-разработчики должны делать свои сайты с учётом этого, хотя пользуется этим браузером 3 человека. Это фейк.
Какие факты я искажаю?
Какие факты я искажаю?
> Там, где интернет нужен — есть технические средства в актуальном, для потребления интернета, состоянии.
Вообще-то совсем даже нет, скорее наоборот. Но в моём случае такие технические средства имеются. И у меня есть техническая возможность заплатить за это деньги, чтобы я мог использовать быстрый интернет по работе.
> Какие факты я искажаю?
Что конторе не нужен современный интернет. Это не так. Во внутреннем форуме тема о попытках изменить ситуацию создаётся ежегодно.
>… и как факт может возникнуть мифическая ситуация…
То, что вы пишите — мифическая, моя ситация — конкретная, я её уже разжевал как мог.
>… веб-разработчики должны делать свои сайты с учётом этого…
Я не хочу, чтобы разработчики заморачивались по поводу каждого браузера, не поддерживающего или криво поддерживающего стандарты. Разработчики должны делать сайты в соответствии со стандартами. Стандарт HTML не подразумевает наличие JS в браузере. Готов признать, что картинки-капчи хоть и делают работу в текстовом браузере неудобной, всё же не делают её невозможной совсем, потому что:
1. Я имею возможность сохранить картинку-капчу по урлу и посмотреть её на ме-е-д-д-ленном канале, если графика у меня пашет. Собственно, так я и делаю.
2. Для вопросов поднятия графики/сервера с консоли используются грамотные информационные ресурсы, сделанные грамотными людьми, где картинки-капчи если и используются, то для получения информации не обязательны.
Подведу итог: Я против навязчивого JavaScript.
Вообще-то совсем даже нет, скорее наоборот. Но в моём случае такие технические средства имеются. И у меня есть техническая возможность заплатить за это деньги, чтобы я мог использовать быстрый интернет по работе.
> Какие факты я искажаю?
Что конторе не нужен современный интернет. Это не так. Во внутреннем форуме тема о попытках изменить ситуацию создаётся ежегодно.
>… и как факт может возникнуть мифическая ситуация…
То, что вы пишите — мифическая, моя ситация — конкретная, я её уже разжевал как мог.
>… веб-разработчики должны делать свои сайты с учётом этого…
Я не хочу, чтобы разработчики заморачивались по поводу каждого браузера, не поддерживающего или криво поддерживающего стандарты. Разработчики должны делать сайты в соответствии со стандартами. Стандарт HTML не подразумевает наличие JS в браузере. Готов признать, что картинки-капчи хоть и делают работу в текстовом браузере неудобной, всё же не делают её невозможной совсем, потому что:
1. Я имею возможность сохранить картинку-капчу по урлу и посмотреть её на ме-е-д-д-ленном канале, если графика у меня пашет. Собственно, так я и делаю.
2. Для вопросов поднятия графики/сервера с консоли используются грамотные информационные ресурсы, сделанные грамотными людьми, где картинки-капчи если и используются, то для получения информации не обязательны.
Подведу итог: Я против навязчивого JavaScript.
> Что конторе не нужен современный интернет. Это не так.
Что нужно, а что не нужно конторе — решает руководство. Оно может прислушаться к мнению сотрудников, а может и не прислушиваться. К тому же контора и без быстрого интернета на древних компах выиграла грант на 850 мульёнов.
Руководство решило, что быстрый интернет и новое железо вам без надобности. Это факт.
> Стандарт HTML не подразумевает наличие JS в браузере.
При чём тут HTML? Это одна из технологий. На ряду с JS, Flash и т.д. Хоть и основополагающая в нашем случае. В супе вот основопологающий компонент — вода, это не значит, что боржч нужно делать без свеклы и мяса. ^_^
Подведу итог: просто не пользуйтесь «современным» Интернетом.
Что нужно, а что не нужно конторе — решает руководство. Оно может прислушаться к мнению сотрудников, а может и не прислушиваться. К тому же контора и без быстрого интернета на древних компах выиграла грант на 850 мульёнов.
Руководство решило, что быстрый интернет и новое железо вам без надобности. Это факт.
> Стандарт HTML не подразумевает наличие JS в браузере.
При чём тут HTML? Это одна из технологий. На ряду с JS, Flash и т.д. Хоть и основополагающая в нашем случае. В супе вот основопологающий компонент — вода, это не значит, что боржч нужно делать без свеклы и мяса. ^_^
Подведу итог: просто не пользуйтесь «современным» Интернетом.
Руководство — не контора, а в таких масштабах — так вообще мало что общего у них. Я уже не намекаю даже — руководство не получит прибыли от оплаты дорогостоящего, хорошего доступа в сеть. А контора — получит выгоду.
Да, с HTML выразился неточно. Имел в виду, что веб-сайт — это набор страниц на (X)HTML, а веб-браузер — программа, отображающая (X)HTML. Более никаких обязательств в браузер не закладывается. А мы говорим именно о веб-сайтах и веб-браузерах.
Подведу итог ещё раз: вы не рекомендуете мне пользоваться сайтами, использующими местами глючную, местами — вообще не работающую популярную современную технологию, которая, собственно, работать даже и не должна в силу отсутствия стандарта.
P.S. Под отсутствием стандарта я понимаю не JS в отдельности, а его связку с HTML.
Да, с HTML выразился неточно. Имел в виду, что веб-сайт — это набор страниц на (X)HTML, а веб-браузер — программа, отображающая (X)HTML. Более никаких обязательств в браузер не закладывается. А мы говорим именно о веб-сайтах и веб-браузерах.
Подведу итог ещё раз: вы не рекомендуете мне пользоваться сайтами, использующими местами глючную, местами — вообще не работающую популярную современную технологию, которая, собственно, работать даже и не должна в силу отсутствия стандарта.
P.S. Под отсутствием стандарта я понимаю не JS в отдельности, а его связку с HTML.
UFO just landed and posted this here
Ладно линкс, я вот иногда телнетом страницы открываю :)
irony on
Я сделал текстовую капчу и теперь вы можете зайти на мой фото-сайт и с текстового браузера, ура!
irony off
Я сделал текстовую капчу и теперь вы можете зайти на мой фото-сайт и с текстового браузера, ура!
irony off
display:none отлично работает уже долгое время на нескольких моих сайтах. Спама и так немного приходило, а так вообще нет. Видимо, пока в CSS боты не суются. Надолго ли?
у меня на сайте стоит супер-защита в виде сложной загадки (для комментатора):
«что такое скользкое зеленое, на ля- начинается на -гушка заканчивается» принимаются ответы как «лягушка», так и «танк»)))
«что такое скользкое зеленое, на ля- начинается на -гушка заканчивается» принимаются ответы как «лягушка», так и «танк»)))
На одном из моих сайтов была форма для связи, спустя некоторое время туда стал сыпаться спам. Решение оказалось простым)
Скрытое поле с кодом, обычное поле для ввода кода, и этот же код, выведенный рядом простым текстом.
На стороне сервера эти два поля проверялись на соответствие.
Скрытое поле с кодом, обычное поле для ввода кода, и этот же код, выведенный рядом простым текстом.
На стороне сервера эти два поля проверялись на соответствие.
Спасибо за информацию, узнал пару новых способов защиты для себя. Вообще, мне идея капчи уже давно кажется порочной с появлением глазоломательных картинок. По большому счету проблемы спама, автоматических регистраций и т.д. — это проблемы сервиса, а не пользователя. Забавно порой выглядит, когда в форме регистрации, которая расчитана на ускорение этой процедуры: минимум полей, приятная валидация — стоит нечитаемая капча. В итоге все прелести формы нивелируется ей, когда тратишь на прочтение капчи несколько десятков секунд, а то и несколько перезагрузок страницы в случае ошибки.
Поэтому и стараюсь в своих проектах обходиться защитами, которые скрыты от пользователя. В случае целенаправленной атаки все равно никто и ничто не спасет.
Поэтому и стараюсь в своих проектах обходиться защитами, которые скрыты от пользователя. В случае целенаправленной атаки все равно никто и ничто не спасет.
Полностью разделяю Ваше мнение.
Есть подозрение, что объём запаривания есть константа. Либо программист запаривается на грамотную реализацию защиты формы, либо пользователь запаривается на решение капчи.
Есть подозрение, что объём запаривания есть константа. Либо программист запаривается на грамотную реализацию защиты формы, либо пользователь запаривается на решение капчи.
Вы забыли в эту константу добавить популярность и необходимость движка, для которого это все делается. Если популярность сервиса стремится к нулю то и сложность защиты для юзверя и программиста могут быть минимальны. Если же отдача от автозаполнения и популярность(распространенность) стремится к бесконечности, то запариваются и пользователи и программисты.
Спам на незащищенные формы сыпется автоботами, которые вобще ничего не проверяют.
P.S. Извините конечно, но посоветовал бы всем разработчикам, кидающим свои идеи попробовать самим устроить целенаправленную атаку на сайт с данными защитами. хотя бы мысленно. Если ваш сайт никому не нужен то достаточно сабмитеть через форму созданную в js и не извращаться, а если нужен, то это все детские задачки по сравнению с распознаванием капчи, так что так извращаться тоже нет смысла.
Спам на незащищенные формы сыпется автоботами, которые вобще ничего не проверяют.
P.S. Извините конечно, но посоветовал бы всем разработчикам, кидающим свои идеи попробовать самим устроить целенаправленную атаку на сайт с данными защитами. хотя бы мысленно. Если ваш сайт никому не нужен то достаточно сабмитеть через форму созданную в js и не извращаться, а если нужен, то это все детские задачки по сравнению с распознаванием капчи, так что так извращаться тоже нет смысла.
> Минимальное время заполнения формы...
Не знаю насколько развиты сегондяшние боты. Вот, что я думаю. А если как-нибудь определять, что что-то именно вводится в поле? т.е.:
1. Ведь человеку необходимо какое-то время, чтобы заполнить поле (хотя многие используют «автозаполнялки» — тут надо тоже подумать)…
2. Ну и, грубо говоря, как-то использовать onChange (это я «придумал», исходя из того, что боты, возможно, отправляют данные на обработку тупо запросом)
Не знаю насколько развиты сегондяшние боты. Вот, что я думаю. А если как-нибудь определять, что что-то именно вводится в поле? т.е.:
1. Ведь человеку необходимо какое-то время, чтобы заполнить поле (хотя многие используют «автозаполнялки» — тут надо тоже подумать)…
2. Ну и, грубо говоря, как-то использовать onChange (это я «придумал», исходя из того, что боты, возможно, отправляют данные на обработку тупо запросом)
По идее, можно на onChange заполнять какое-то секретное поле, например, хешом от текущего значения поля.
Аналогичная защита вычислять этот хеш onSubmit формы.
И то, и другое, безусловно, поможет от многих ботов.
А вот с автозаполнялками, и правда, возможная проблема. Хотя пользователю всё равно нужна хотя бы секунда, чтобы пробежать глазами форму и дотянуться до submit'а.
Аналогичная защита вычислять этот хеш onSubmit формы.
И то, и другое, безусловно, поможет от многих ботов.
А вот с автозаполнялками, и правда, возможная проблема. Хотя пользователю всё равно нужна хотя бы секунда, чтобы пробежать глазами форму и дотянуться до submit'а.
UFO just landed and posted this here
По-моему, ничего толкого нет.
Уже сто раз было сказано, что чтобы отсечь сайт от случайных ботов, достаточно заюзать какой-нибудь hidden-параметр, а от нацеленных на ваш ресурс ботов вы вряд ли сможете навсегда спастись.
Уже сто раз было сказано, что чтобы отсечь сайт от случайных ботов, достаточно заюзать какой-нибудь hidden-параметр, а от нацеленных на ваш ресурс ботов вы вряд ли сможете навсегда спастись.
Не спастись. Капча сделает часть попыток неудачными. Другие способы требуют лишь время на адаптацию :)
Помнится, на Mail.ru одно время была достаточно мощная защита: там и имена полей генерировались случайно и, что было самым сложным для взлома, это обновляющаяся каждые 20 секунд капча. Но вскоре они вернули «традиционную» и стало легче :)
P.S. Занимался этим не для спама.
Помнится, на Mail.ru одно время была достаточно мощная защита: там и имена полей генерировались случайно и, что было самым сложным для взлома, это обновляющаяся каждые 20 секунд капча. Но вскоре они вернули «традиционную» и стало легче :)
P.S. Занимался этим не для спама.
Кстати, не знаю как сейчас, а год назад в жж капча была «фиктивная». Вместе с капчей пользователю в форме высылался специальный ID, жёстко связаный с переданной капчей. Причём сервер не запоминал кому какую капчу он выслал. Так что можно было всегда пользозваться одним сочетанием (капча-код). В итоге регистрация шла безо всяких капчей :)
Спасаюсь вот таким примитивным методом:
Не скажу, что сайт сильно посещаемый или что он под прицелом у ботов, но до применения этого метода приходило через web-форму по 10 писем в день. После модернизации — 1 раз в месяц, и то не факт, что сообщение не разослано «вбивалами».
1. <input type="hidden" name="xcode" id="r2d2" value="0">
2. document.getElementById("r2d2").value = 776;
3. проверяю в php $_REQUEST['r2d2'] == 776Не скажу, что сайт сильно посещаемый или что он под прицелом у ботов, но до применения этого метода приходило через web-форму по 10 писем в день. После модернизации — 1 раз в месяц, и то не факт, что сообщение не разослано «вбивалами».
Наверное $_REQUEST['xcode']
лучше проверяйте $_POST
Я пользуюсь в том числе и браузером, в котором нет JavaScript. Я иду лесом?
UFO just landed and posted this here
Мне вот этот вариант нравится. Просто реализуется, не запарно.
Вариант, когда hidden-поле не заполняется изначально — не очень. Ведь бот может тупо не заполнять пустые hidden'ы.
Такая штуковинка совместно с каким-либо методом (таким же «не запарным») вполне подойдет для большинства ресурсов.
Можно, для предоставления «определенной степени уверенности» (не говорю «полной» — это не возможно), при проверке пары наших проверок, в случае недочета в одной из них, выводить уже капчу сложнее. Например, тупо-картинку.
Автору: За статью — спасибо
Вариант, когда hidden-поле не заполняется изначально — не очень. Ведь бот может тупо не заполнять пустые hidden'ы.
Такая штуковинка совместно с каким-либо методом (таким же «не запарным») вполне подойдет для большинства ресурсов.
Можно, для предоставления «определенной степени уверенности» (не говорю «полной» — это не возможно), при проверке пары наших проверок, в случае недочета в одной из них, выводить уже капчу сложнее. Например, тупо-картинку.
Автору: За статью — спасибо
Можно генерить имена полей формы динамически, например: либо конечный набор «вариаций», либо какое-нибудь более экзотическое другое ухищрение.
Например: на сервере создаём таблицу перестановок и эталонное положение полей формы, потом выбираем произвольную перестановку из этой таблицы, пишем её номер в хидден и перставляем поля. Для пользователя всё будет прозрачно — бот врядли поймёт, что поле «email» в данный конкретный момент это «Имя вашей собаки».
Лучшее средство от ботов — закрытый сайт, к сожалению.
Например: на сервере создаём таблицу перестановок и эталонное положение полей формы, потом выбираем произвольную перестановку из этой таблицы, пишем её номер в хидден и перставляем поля. Для пользователя всё будет прозрачно — бот врядли поймёт, что поле «email» в данный конкретный момент это «Имя вашей собаки».
Лучшее средство от ботов — закрытый сайт, к сожалению.
Спасибо, очень любопытный способ. Можно его обобщить: генерить произвольные названия полей (типа «DD324-SDF6P-3054»), а соответствие хранить на сервере. Тогда боту даже придраться не к чему (кроме, конечно, ).
А про закрытый сайт, Вы, конечно, правы.
Я вот вынашиваю идею разрешать анонимусам что-либо делать только по заполнении капчи. Выбрать не очень тривиальную капчу и приписать «хотите без капчи? регестрируйтесь!».
А про закрытый сайт, Вы, конечно, правы.
Я вот вынашиваю идею разрешать анонимусам что-либо делать только по заполнении капчи. Выбрать не очень тривиальную капчу и приписать «хотите без капчи? регестрируйтесь!».
UFO just landed and posted this here
Генерирование имен полей имеет дополнительный эффект.
Перестает всплывать подсказка на наиболее-часто встречающихся элементах форм. Например email
Перестает всплывать подсказка на наиболее-часто встречающихся элементах форм. Например email
UFO just landed and posted this here
Пока что мне очень нравятся решения Facebook Connect и, несколько менее, OpenID. И регистрироваться не заставляешь, и хоть какая-то аутентификация есть.
А что помешает зарегить InternetID на бомжей и отдать их ботам?
Мечта для Большого Брата.
Выглядеть будет так: пользователь 4387276467ru77 отключен от Сети на 15 суток за использование мата в комментарии.
Выглядеть будет так: пользователь 4387276467ru77 отключен от Сети на 15 суток за использование мата в комментарии.
Добавлять поля через js, тогда боту нечего будет заполнять :)
Или как вариант можно использовать отличный плагин для jQuery — jEditable. В сорсе тэгов форм абсолютно нет, бот по сути и не поймёт, что со страницы можно что-либо отправлять.
на тематическом сайте можно задавать несложный вопрос
например, на форуме Counter-strike я прошу при регистрации указывать адрес нашего игрового сервера
спасает и от ботов, и от спамеров, которые капчу распознают на ура :)
например, на форуме Counter-strike я прошу при регистрации указывать адрес нашего игрового сервера
спасает и от ботов, и от спамеров, которые капчу распознают на ура :)
Это довольно интересная идея.
Вообще, мне кажется, что проблема спамеров-людей совсем не за горами. Чем больше пользователи доверяют всяческим page rank, чем больше user-generated сontent, чем дешевле рабочая сила и чем больше распространение интернета, тем существеннее эта проблема.
Я бы даже сказал, что проблема спамеров-людей заслуживает отдельного поста.
Вообще, мне кажется, что проблема спамеров-людей совсем не за горами. Чем больше пользователи доверяют всяческим page rank, чем больше user-generated сontent, чем дешевле рабочая сила и чем больше распространение интернета, тем существеннее эта проблема.
Я бы даже сказал, что проблема спамеров-людей заслуживает отдельного поста.
к сожалению, узко применимо: нужно задать вопрос, на который все потенциальные допропорядочные пользователи ответ знают, а спамер — нет
а так и вправду, на моем форуме спама нет уже года полтора
а так и вправду, на моем форуме спама нет уже года полтора
сталкнулся с данной проблемой где-то год назад, до сих пор покоя нет, хотя удаление происходит оперативно.
По сути что не писать, все работать будет, но как только ваш ресурс наберет популярности(внушительной), то начнут точить ботов под вас, а там уже кто кого.
Боты еще мышкой не двигают, но это — тоже js-решение. Несколько сабмитов — тоже интересно, но бот может «нажать» на все.
Припоминая общие принципы защиты данных, есть такое понятие стоимость взлома. Не существует ничего, что нельзя взломать. Вопрос в том, сколько это будет стоить. Стратегия защиты любой системы это максимальное увеличение затрат денег и времени на взлом объекта. В идеале стоимость взлома для злоумышленника должна быть больше потенциальной прибыли.
Расширю Ваше рассуждение. Для систем, где есть интерфейс пользователя можно ввести такое понятие, как стоимость защиты. Это количество сил, которое тратит пользователь на поддержание стратегии защиты.
Допустим, анализ ДНК имеет большую стоимость взлома, но и большую стоимость защиты. А вот методы из поста имеют весьма среднюю стоимость взлома, но нулевую стоимость защиты.
Надо искать такой метод, чтобы (стоимость_взлома/стоимость_защиты) была как можно больше… Где б такой найти…
Допустим, анализ ДНК имеет большую стоимость взлома, но и большую стоимость защиты. А вот методы из поста имеют весьма среднюю стоимость взлома, но нулевую стоимость защиты.
Надо искать такой метод, чтобы (стоимость_взлома/стоимость_защиты) была как можно больше… Где б такой найти…
Вы не учитываете тот факт, что человеку может быть банально интересно написать бота. А тут начнется дело принципа и стоимость взлома уйдет на второй план, скрывшись за квалификацией заинтересовавшегося человека :)
тоже думал над этим и очень рад что уже есть решения
Удивительно, но многие простенькие боты заполняют все неизвестные поля.В этом ничего удивительного, в той теме, где мы это обсуждали я объяснял почему это так :) И так делают не просто многие боты, таким интеллектом обладает большинство ботов-автоматов. Даже если автомат заточен под конкретный движок, пара изменений в стандарте форм этого движка — и автобот обломается.
1. Время заполнения формы учитывать нельзя, так как у пользователя может работать автозаполнение форм, и он ее может заполнить «неожиданно» быстро. Если форма долго не сабмитится, то человек мог уйти попить кофе — это нормально.
2. Капча вообще была придумана только потому, что у людей может не быть JS. Если забить на тех у кого нет JS — то форму можно полностью генерить яваскриптом передавая с сервера данные в виде массива/объекта для генерации+ключ для сверки. Боты задолбаются. Возможности защиты с JS — практически безграничны, но все таки его некоторые отключают.
3. Проверка юзерагентов совершенно неэффективна. Бот скорее будет маскироваться под браузер, нежели слать специфичный для него заголовок (это вообще глупость какая то — зачем ему это надо?)
4. Про бан по IP нужно забыть совсем. Мало того, что за одним IP может сидеть куча невиноватого народу, так и бот может орудовать с компьютера жертвы, которая о нем не знает (вирус, то бишь). Соответственно про «ловушку» можно тоже забыть. Бан по IP более менее работает только в локальных сетях, там это имеет смысл.
5. от целенаправленного и/или человеческого вскрытия не спасет ничего :)
UFO just landed and posted this here
Большое спасибо за замечательную критику.
Мне всё больше кажется, что самое разумное решение — гибрид. По умолчанию форма защищена каким-либо JS-методом. Если форма была засабмичена не корректно, то возвращается ошибка и просьба заполнить не очень тривиальную капчу. Вроде, это и довольно user-friendly (у большинства JS всё же работает), защищает и от ботов и работает с пользователями без JS (пусть со второго раза).
Мне всё больше кажется, что самое разумное решение — гибрид. По умолчанию форма защищена каким-либо JS-методом. Если форма была засабмичена не корректно, то возвращается ошибка и просьба заполнить не очень тривиальную капчу. Вроде, это и довольно user-friendly (у большинства JS всё же работает), защищает и от ботов и работает с пользователями без JS (пусть со второго раза).
Ваша логика мне симпатична. Согласен.
Да, хороший подход. Причем делать так хорошо. На первом этапе генерить форму полностью яваскриптом, тогда проходящие мимо автоботы даже не узнают, что тут была форма, и не будут ломиться, так что заодно снизим нагрузку на сервер :)
В eLinks работать не будет, но количество отсеянных «честных» юзеров уже сильно меньше. Мне нравится.
Спасибо за доброе слово :)
Поддержка текстовых браузеров, как и поддержка пользователей с ограниченными возможностями — очень непростая задача. Решать эту задачу имеет смысл для всего сайта в целом, не только для нескольких форм.
Если речь идёт о развлекательном ресурсе, то, я думаю, можно сделать довольно большие предположения о возможностях пользователя (браузере, скриптах, плагинах).
Однако, для серьёзного ресурса (как то банк или какой-нибудь государственный институт) поддержка текстовой версии просто необходима. Защита форм подобных ресурсов, думаю, заслуживает отдельного поста.
Поддержка текстовых браузеров, как и поддержка пользователей с ограниченными возможностями — очень непростая задача. Решать эту задачу имеет смысл для всего сайта в целом, не только для нескольких форм.
Если речь идёт о развлекательном ресурсе, то, я думаю, можно сделать довольно большие предположения о возможностях пользователя (браузере, скриптах, плагинах).
Однако, для серьёзного ресурса (как то банк или какой-нибудь государственный институт) поддержка текстовой версии просто необходима. Защита форм подобных ресурсов, думаю, заслуживает отдельного поста.
На случай если забить на тех, у кого нет JS, почему бы не генерить не всю форму, а только специальное проверочное поле JavaScript'ом (тот же ключ)?
Впрочем, вы верно отметили — все-таки некоторые его отключают, что концептуально неверно для интернет-ресурсов.
Впрочем, вы верно отметили — все-таки некоторые его отключают, что концептуально неверно для интернет-ресурсов.
Для тех кто отключает скрипты можно показывать обычную html-форму с капчей
скрипт удаляет/скрывает старую форму и генерит новую без капчи.
скрипт удаляет/скрывает старую форму и генерит новую без капчи.
Возможности защиты с JS — практически безграничны, но все таки его некоторые отключают.
На самом деле это не так. Сейчас многие боты снабжены рендеренгом страниц. И они могут полноценно работать с DOM моделью. Как это сделано? Просто — они используют заточенный под себя движок FF.
Так что это тоже не вариант.
Откуда данные про «многие»? Есть какая то статистика?
Полностью согласен.Технических средств для програмной обработки JavaScript существует множество: COM интерфейс к эксплореру, watir и firewatir, XUL приложение или отдельный аддон для фаерфокса, HtmlUnit на Java, Adobe AIR, Jaxer. Так что способы, расчитаные просто на необработку ботом джаваскрипта все таки ограничены.
Ниже упоминают флеш и, как по мне, програмно взаимодействовать с флешем — боле сложная задача чем аналогичная с джаваскриптом.
Так же теоретически интересен способ с применением data minig и обученого класификатора, если полагать, что боты в своем большинстве ведут себя похожим образом
Ниже упоминают флеш и, как по мне, програмно взаимодействовать с флешем — боле сложная задача чем аналогичная с джаваскриптом.
Так же теоретически интересен способ с применением data minig и обученого класификатора, если полагать, что боты в своем большинстве ведут себя похожим образом
Уже второй год использую на своих блогах смешанный алгоритм:
1. скрытое поле «email»
2. зашифрованные имена полей (привязываются к текущему часу, ip, и useragent'у)
Если на сервер приходит поле email — форма возвращается в своё положение. В других случаях зашифрованные поля дешифруются и добавляются.
За всё время был только один случай, когда пролез бот — видимо автор бота его настроил только-что и запустил, но он проработал до конца текущего часа и успел прислать только 2 комментария на единственную запись из тысячи.
1. скрытое поле «email»
2. зашифрованные имена полей (привязываются к текущему часу, ip, и useragent'у)
Если на сервер приходит поле email — форма возвращается в своё положение. В других случаях зашифрованные поля дешифруются и добавляются.
За всё время был только один случай, когда пролез бот — видимо автор бота его настроил только-что и запустил, но он проработал до конца текущего часа и успел прислать только 2 комментария на единственную запись из тысячи.
А что будет, если человек начал заполнять форму в 13:59, а отправил в 14:00?
Час разный, имена полей уже должны будут быть другими. Т.е. когда скрипт будет анализировать POST-данные, то имена сгенерированных полей уже должны отличаться.
Или связка «зашифрованное имя поля» — «настоящее имя поля» хранится в самой форме тоже?
Час разный, имена полей уже должны будут быть другими. Т.е. когда скрипт будет анализировать POST-данные, то имена сгенерированных полей уже должны отличаться.
Или связка «зашифрованное имя поля» — «настоящее имя поля» хранится в самой форме тоже?
Можно проверять $HTTP_REFERER. Обычно при сабмите формы человеком с браузером реферер не пуст и содержит адрес сайта.
Если же сабмит был сделан простым массовым ботом — реферер будет пустым.
Если же сабмит был сделан простым массовым ботом — реферер будет пустым.
Спасибо, хороший метод. Чем-то сродни проверки user-agent, мне кажется.
Ещё чуть-чуть и стоит обобщить эти методы в «проверка заголовков запроса».
Ещё чуть-чуть и стоит обобщить эти методы в «проверка заголовков запроса».
Нет, плохой. Передача реферера — воля браузера, пользователя и файрвола. А также админа прокси-сервера, через который живет пользователь. В каждой инстанции этот заголовок может быть изменен или запрещен пользователем. Боту с другой стороны ничего не мешает при обходе сайта запомнить URI с которого он попал на страницу с формой и передать этот URI в заголовке HTTP_REFERER.
Фаервол может менять реферрера? До чего техника дошла…
А про прокси сервер и браузер Вы совершенно правы. Этого достаточно, чтобы о реферре забыть.
А про прокси сервер и браузер Вы совершенно правы. Этого достаточно, чтобы о реферре забыть.
Ну как бы Referer — это просто один из заголовков, передаваемых клиентом серверу. По стандарту он не обязателен, как и большинство других. Например такой известный файрвол Outpost смело вгрызается в http-соединения и вырезает такой, казалось бы безобидный заголовок, как Accept-Encoding, после чего у вас полностью перестает работать gzip-сжатие, а вы даже об этом и не узнаете, разве что в статистике заметите более высокий расход трафика. Так было, когда я им пользовался. И сделали так потому(видимо), что Outpost не умел распаковывать данные на лету или это оказывалось очень накладно по ресурсам. Запрет рефереров — это средство от паранойи, чтобы никто не мог понять о вас даже таких пустяков, как какой вы посещали сайт, перед тем, как придти на этот.
Про реферер можно еще забыть из-за такой банальности, как закладки. Пришел я на страницу формы, положил ее в закладки со словами — потом отправлю а через какое то время открыл эту страницу и отправил форму, с пустым рефером :)
Про реферер можно еще забыть из-за такой банальности, как закладки. Пришел я на страницу формы, положил ее в закладки со словами — потом отправлю а через какое то время открыл эту страницу и отправил форму, с пустым рефером :)
Спасибо за объяснение. Честно говоря не знал, что фаерволы изменяют что-то на уровне приложения. Приоткрыло глаза на мир :)
Ещё раз, я согласен, что про метод анализа реферрера можно забыть.
Ещё раз, я согласен, что про метод анализа реферрера можно забыть.
Меняют они на уровне трафика, но иногда эти изменения приводят к другому сценарию поведения приложения
Забывать не надо. Просто, если referer не заполнен или некорректен — показываем боту (или человеку) капчу :)
Можно. Однако, для меня решающим доводом был тот факт, что если на страничку попали по букмарке то реферрер, обычно, пустой.
Опять же, если ввести несколько способов защиты и функцию подозрительности, то пустой реферрер может быть +0.5 к подоздрительности запроса.
Опять же, если ввести несколько способов защиты и функцию подозрительности, то пустой реферрер может быть +0.5 к подоздрительности запроса.
> Можно. Однако, для меня решающим доводом был тот факт, что если на страничку
> попали по букмарке то реферрер, обычно, пустой.
> попали по букмарке то реферрер, обычно, пустой.
> Можно. Однако, для меня решающим доводом был тот факт, что если на страничку
> попали по букмарке то реферрер, обычно, пустой.
Да, в этом случае он будет пустой. Но если мы с этой страницы отправим форму, то в скрипте, который эту форму обрабатывает, реферер будет равен адресу страницы.
> попали по букмарке то реферрер, обычно, пустой.
Да, в этом случае он будет пустой. Но если мы с этой страницы отправим форму, то в скрипте, который эту форму обрабатывает, реферер будет равен адресу страницы.
> Про реферер можно еще забыть из-за такой банальности, как закладки. Пришел я на
> страницу формы, положил ее в закладки со словами — потом отправлю а через какое то
> время открыл эту страницу и отправил форму, с пустым рефером :)
В этом случае реферер не будет пустым.
> страницу формы, положил ее в закладки со словами — потом отправлю а через какое то
> время открыл эту страницу и отправил форму, с пустым рефером :)
В этом случае реферер не будет пустым.
Современные роботы очень хорошо передают реферы
Безусловно. Более того, полностью полагаться на реферер нельзя, как и на другие штуки пришедшие от пользователя.
Но если идет большой поток спама через форму, можно и нужно анализировать рефереры ботов для поиска закономерностей. Часто они находятся и в этом случае отсечку ботов очень просто реализовать.
Но если идет большой поток спама через форму, можно и нужно анализировать рефереры ботов для поиска закономерностей. Часто они находятся и в этом случае отсечку ботов очень просто реализовать.
UFO just landed and posted this here
Еще не реализовывал, но мысль примерно такая.
Не использовать формы вообще. Т.е. накидать div'ов, прописать им такие стили, чтобы были походи на форму. Далее перехватывать все, что вводится в форму, когда курсор в поле определенного div'а ( в jquery это можно сделать, используя keypress ). Для пользователя писать перехваченое в div, а реално все данные записывать в js массив. Далее, при нажатии кнопки регистрации, через ajax отсылать этот массив серверу, где будет какая-либо банальная проверка юзер-агента и т.п. Учитывая, что боты чаще используют post или get, тут явно возникнут у них сложности.
Что думаете по поводу этой затеи?
Не использовать формы вообще. Т.е. накидать div'ов, прописать им такие стили, чтобы были походи на форму. Далее перехватывать все, что вводится в форму, когда курсор в поле определенного div'а ( в jquery это можно сделать, используя keypress ). Для пользователя писать перехваченое в div, а реално все данные записывать в js массив. Далее, при нажатии кнопки регистрации, через ajax отсылать этот массив серверу, где будет какая-либо банальная проверка юзер-агента и т.п. Учитывая, что боты чаще используют post или get, тут явно возникнут у них сложности.
Что думаете по поводу этой затеи?
Эх… Пока писал, уже похожее написали.)
Этим вы только перегрузите страницу пользователя js-ом. Шевелиться это хозяйство будет не моментально, как если использовать форму. А ломаться такая защита будет даже проще, чем писалась :)
UFO just landed and posted this here
А разве нет способа оградить отправку данных через Ajax с другого домена? По моему $.post так точно работать не будет.
UFO just landed and posted this here
Т.е. проверка через что был отправлен запрос тоже бессильна?
К примеру, я делаю такую проверку во всех скриптах, которые отрабатываются через Ajax:
К примеру, я делаю такую проверку во всех скриптах, которые отрабатываются через Ajax:
if($_SERVER['HTTP_X_REQUESTED_WITH'] == 'XMLHttpRequest') {
// тут код скрипта
} else {
// тут выдаётся сообщение о том, что запрос был послан не через Ajax
}
* This source code was highlighted with Source Code Highlighter.
Есть ещё способ, который родился в процессе чтения этого поста.
Каждый раз рандомно перебирать указанные вами «незаметные» способы защиты от спама. Теоретически, обойти можно, но работы для спамеров будет уйма, учитывая, что его постоянно будет сбивать с толку то, что методы антиспама каждый раз разные. Скорее всего плюнет и пойдет ломать другой сайт :)
Каждый раз рандомно перебирать указанные вами «незаметные» способы защиты от спама. Теоретически, обойти можно, но работы для спамеров будет уйма, учитывая, что его постоянно будет сбивать с толку то, что методы антиспама каждый раз разные. Скорее всего плюнет и пойдет ломать другой сайт :)
Есть сайты, где используются сразу все методы. И они так же ломаются. Отличие от вашего будет только в том, что чтобы увидеть способы защиты на том сайте, страницу с формой надо будет загрузить лишь раз, а страницу с вашего сайта — несколько раз :)
Более того, эти способы можно применять все вместе!
Поскольку все они прозрачны для пользователя, то нам совершенно ничего не мешает :)
Поскольку все они прозрачны для пользователя, то нам совершенно ничего не мешает :)
Тут подумал. А как насчет заполнения форм на флеше?
Вообще, интересный вопрос.
Мне кажется, основная проблема состоит в том, что флеш установлен далеко не везде. Особенно на мобильных устройствах.
Кроме этой, особых фундаментальных проблем я не вижу. Однако, и форм таких нигде не видно. Значит, мы о чём-то забываем.
Мне кажется, основная проблема состоит в том, что флеш установлен далеко не везде. Особенно на мобильных устройствах.
Кроме этой, особых фундаментальных проблем я не вижу. Однако, и форм таких нигде не видно. Значит, мы о чём-то забываем.
Можно реализовать примерно так:
1) Ставим на страницу флешку, в которой нет графики, просто одна строка AS:
2) JS:
Если у юзера флеша нет, то переменная init будет 0.
1) Ставим на страницу флешку, в которой нет графики, просто одна строка AS:
getUrl('javascript:flash_ok();'); stop();2) JS:
<script language='JavaScript'>
init = 0; setTimeout(init_form,1500);
function flash_ok() { init = 1; }
function init_form() {
if (init == 1) { //загружаем флеш-форму } else { //загружаем форму через ajax }
</script>
Если у юзера флеша нет, то переменная init будет 0.
А какая принципиальная разница от джава скрипта?
Сформировать необходимый запрос боту, при желании, не помешает.
Для простых случаев хватит и скрытого поля, для более сложных — методы со скриптами или капча, ну а для совсем сложных — скрипты+капча, мониторинг вводимых данных «в живую» и т.п. Ну и флеш, при желании можно сюда же:
«Дойдите в этой flash игре до 25 уровня, мы должны убедиться, что вы — не бот.»
Сформировать необходимый запрос боту, при желании, не помешает.
Для простых случаев хватит и скрытого поля, для более сложных — методы со скриптами или капча, ну а для совсем сложных — скрипты+капча, мониторинг вводимых данных «в живую» и т.п. Ну и флеш, при желании можно сюда же:
«Дойдите в этой flash игре до 25 уровня, мы должны убедиться, что вы — не бот.»
как то у меня блог на вротпрессе атаковали спамботы, убрал из интерфейса (то бишь подправил модуль) форму для url, текстовое поле для ввода урла исчезло, но боты почему то все равно могли присылать свой спам…
как вариант — несколько кнопок отправить, и прям перед ними надпись «Нажмите левую кнопку, что бы отправить»(и улучшение — кнопки сделать на обычной картинке и реализовать с помошью, и вообще тогда можно генерировать кнопок)
так же можно сделать базу загадок, из которых брать случайную, и задавать, перед отправкой в попапе…
если с помощью js можно отследить использование скрола мыши — то боты точно мышкой не пользуются (это для тех сайтов, где контент ниже экрана)
для ленивых — капча наоборот: нарисован простой символ, например L, и надо нарисовать с помощью js\flash такой же…
как вариант — несколько кнопок отправить, и прям перед ними надпись «Нажмите левую кнопку, что бы отправить»(и улучшение — кнопки сделать на обычной картинке и реализовать с помошью, и вообще тогда можно генерировать кнопок)
так же можно сделать базу загадок, из которых брать случайную, и задавать, перед отправкой в попапе…
если с помощью js можно отследить использование скрола мыши — то боты точно мышкой не пользуются (это для тех сайтов, где контент ниже экрана)
для ленивых — капча наоборот: нарисован простой символ, например L, и надо нарисовать с помощью js\flash такой же…
*… картинке и реализовать с помошью *
с помощью тега imagemap
А если браузер текстовый?
А еще есть слепые люди и у них тоже есть права использовать звуковые браузеры.
Я встречал звуковые капчи.
Ага, организованы они на флеше (напр. reCaptcha), или с моего последнего использования (e)Links научился отрисовывать флеш в консоли?
Лично к lost_shadow: Может хватит упоминать о текстовых браузерах?
Лично к lost_shadow: Может хватит упоминать о текстовых браузерах?
>если с помощью js можно отследить использование скрола мыши — то боты >точно мышкой не пользуются (это для тех сайтов, где контент ниже экрана)
у меня на ноутбуке нету скролла мышки, прокручиваю страницу курсорными клавишами и PgUp/PgDn. Это плохой сопособ защиты.
у меня на ноутбуке нету скролла мышки, прокручиваю страницу курсорными клавишами и PgUp/PgDn. Это плохой сопособ защиты.
> но боты почему то все равно могли присылать свой спам
Боты продолжают слать в POST запросе переменную с url
Боты продолжают слать в POST запросе переменную с url
Странно, что так мало читателей оценили данный топик. Тема-то очень актуальная, а методы расписаны отлично! Я, например, уже замучился чистить комментарии у себя в блоге, несмотря на капчу. Эта статья очень во время появилась. Спасибо!
Видели регистрацию на cracklab?
Суть в том что нужно ответить на вопрос по теме.
Если например на хабре то нужно ответить на вопрос по статье к которой хочется сделать коментарий.
Чтобы написать коментарий нужно понимать про что статья.
Например для этой статьи вопрос мог быть бы таким:
Что можно подсчитать для всех полей формы?
(ответы: хэш, контрольная сумма)
Да для каждой статьи автор сам придумывает вопрос и ответы в админке
Индейцы могут пропустить
Суть в том что нужно ответить на вопрос по теме.
Если например на хабре то нужно ответить на вопрос по статье к которой хочется сделать коментарий.
Чтобы написать коментарий нужно понимать про что статья.
Например для этой статьи вопрос мог быть бы таким:
Что можно подсчитать для всех полей формы?
(ответы: хэш, контрольная сумма)
Да для каждой статьи автор сам придумывает вопрос и ответы в админке
Индейцы могут пропустить
Метод довольно интересный. Степень защищённости от ботов (да и спамеров) довольно высока. Но, боюсь, многих пользователей отталкнёт такой школьный тест.
Впрочем, для специфического ресурса — вполне!
P. S. (оффтоп) а кто такие индейцы?
Впрочем, для специфического ресурса — вполне!
P. S. (оффтоп) а кто такие индейцы?
Ну в данном случае особо говорить об user-friendly не приходится, а ведь от части из-за этого автор поднял данный вопрос и предлагал соответствующие способы решения.
Во-первых, вы предлагаете по сути вариант капчи, а топик о том, как обойтись без нее
Во-вторых, пример с хабром и комментариями совсем не в тему, для комментирования нужно быть зарегестрированным, просить же зарегестрированных ответить на вопрос — в высшей степени издевательство и стремление к смерти ресурса. Защищать надо только форму регистрации/авторизации.
В-третьих, ваше слово-ответ узнается один раз, после чего натравленный бот работает уже без помех.
Во-вторых, пример с хабром и комментариями совсем не в тему, для комментирования нужно быть зарегестрированным, просить же зарегестрированных ответить на вопрос — в высшей степени издевательство и стремление к смерти ресурса. Защищать надо только форму регистрации/авторизации.
В-третьих, ваше слово-ответ узнается один раз, после чего натравленный бот работает уже без помех.
Очень хороший способ.
Поможет отфильтровать не только тупых ботов но и остальных людей не в теме: кто не прочитал до конца статью, кому лениво отвечать на один и тот же вопрос, кто не очень понял о чем статья и прочих.
В итоге останется три с половиной зарегистрированных пользователя (кармодрочеры?), между ними произойдёт очень содержательная беседа не интересная никому.
Поможет отфильтровать не только тупых ботов но и остальных людей не в теме: кто не прочитал до конца статью, кому лениво отвечать на один и тот же вопрос, кто не очень понял о чем статья и прочих.
В итоге останется три с половиной зарегистрированных пользователя (кармодрочеры?), между ними произойдёт очень содержательная беседа не интересная никому.
Еще можно отшивать все мессаги, где присутствуют строчки типа [url= и <a href=
(Если, конечно, функционалом системы комментирования это не предусмотрено)
Часто такие мессаги и постят боты, во всяком случае, в моей практике.
(Если, конечно, функционалом системы комментирования это не предусмотрено)
Часто такие мессаги и постят боты, во всяком случае, в моей практике.
Лично мне больше нравится вариант с капчей.
Как пример — recaptcha.net/
Но если вашу капчу обходят, тогда имеет смысл заменить форму с сабмитом на отправку посредством JS. Бот который не умеет обрабатывать JS — тут бессилен.
А для того чтоб обойти ботов исполняющих JS — наверно стоит генерить случайным образом name и id у инпутов. Этим самым — автоматическая отправка станет затруднительной…
Как пример — recaptcha.net/
Но если вашу капчу обходят, тогда имеет смысл заменить форму с сабмитом на отправку посредством JS. Бот который не умеет обрабатывать JS — тут бессилен.
А для того чтоб обойти ботов исполняющих JS — наверно стоит генерить случайным образом name и id у инпутов. Этим самым — автоматическая отправка станет затруднительной…
Как идея… движение мышкой по определенной кривой линии создаваемой случайным образом. На подобии управления движением мыши в опере. Сразу снимается вариант бота, т.к. мышью он навряд ли будет двигать )
Увы, но как реализовать это я не знаю.
Увы, но как реализовать это я не знаю.
У себя я просто запретил постить ссылки. И всё. 95% спама отсекается в корне.
Подобное предложение было выше.
Мне кажется, это действенный но не очень user-friendly способ. Ссылки, всё же, не случайно основа интернета.
Мне кажется, это действенный но не очень user-friendly способ. Ссылки, всё же, не случайно основа интернета.
У себя на блоге использую Akismet, хотя для коммерческого использования он платный.
Очень интересно было почитать, спасибо :)
как вариант ещё можно сделать определение была ли наведена мышка на поле ввода капчи если она есть.
Хотя если отправка по Enter'у, то надо как-то по другому отлавливать действия пользователя.
Хотя если отправка по Enter'у, то надо как-то по другому отлавливать действия пользователя.
Практически любое использование JS в обработке формы (с Ajax Отправкой на сервер) серъезно затруднит работу ботов. Ну а как только боты, обрабатывающие JS станут повсеместны, все равно стоит смотреть в сторону новых решений задач капчи…
Вообще CAPTCHA Это «полностью автоматизированный публичный тест Тьюринга для различия компьютеров и людей», так что это есть первозадача.
Вообще CAPTCHA Это «полностью автоматизированный публичный тест Тьюринга для различия компьютеров и людей», так что это есть первозадача.
отличная мысль о скрытом поле, которое автоматом заполняет робот! автору поста респект!
для RoR есть плагин acts_as_snook
github.com/rsl/acts_as_snook/tree/master
описание метода здесь: snook.ca/archives/other/effective_blog_comment_spam_blocker
суть — начисление поинтов по определенным правилам.
оствавил валидный комент ранее — плюс в поинты, оставил камент только из одной ссылки — минус в поинты.
примерно также, как работает spamassassin.
github.com/rsl/acts_as_snook/tree/master
описание метода здесь: snook.ca/archives/other/effective_blog_comment_spam_blocker
суть — начисление поинтов по определенным правилам.
оствавил валидный комент ранее — плюс в поинты, оставил камент только из одной ссылки — минус в поинты.
примерно также, как работает spamassassin.
доп. методы
1. если известно что аудитория 100% русскоязычная, проверять наличие кириллицы. Если ее нет- значит бот или спамер. На клиенте просить ввести хоть слово по русски, на сервере — пускать в трэш.
2. на клиенте обрабатывать через js все урлы в тексте и теги. Вежливо предупреждать что все это почикано. Если отправили с тегами и урлами — значит это сделал бот.
1. если известно что аудитория 100% русскоязычная, проверять наличие кириллицы. Если ее нет- значит бот или спамер. На клиенте просить ввести хоть слово по русски, на сервере — пускать в трэш.
2. на клиенте обрабатывать через js все урлы в тексте и теги. Вежливо предупреждать что все это почикано. Если отправили с тегами и урлами — значит это сделал бот.
Спасибо за идеи.
Я правильно понимаю, что «обрабатывать» урлы — это их вырезать?
Я правильно понимаю, что «обрабатывать» урлы — это их вырезать?
Из фантастических методов можно придумать некий «определитель клавиатурного почерка» на джаваскрипте.
Прошу прощения, нет достаточного времени на прочтение всех комментариев, но надеюсь что я не повторюсь:
Если код страницы не статичен, а генерируется чем бы то ни было (например PHP), то можно создавать некоторое hidden поле с динамическим именем, а например в сессию ($_SESSION) или в куки (т.к. включать сессии для анонимусов это в каком-то смысле дурной тон) складывать название этого поля (в случае с куками — лучше не название поля, а некоторую функцию от него).
При получении же заполненной формы — проверять значение этого поля на совпадение с некоторым даже стандартным значением — уже поможет.
Т.е. мы не присваиваем некоторое «секретное» значение стандартному полю, а наоборот в неизвестное поле складываем стандартное значение.
Суть метода/принцип работы в том, что боты, которых делают ориентируясь на некоторый «стандартный» движок полагаются на статичные имена полей (делается бот/настройка для бота например только для движка punBB, у которого стандартная форма отправки сообщения) — они не могут обрабатывать такие вещи, как динамические поля, т.к. это просто не предусмотрено. Но не панацея конечно.
Отсюда же следует что даже просто поменяв название полей формы в известном движке мы также избавим ресурс от ботов, умеющих опознавать именно этот движок.
Еще проще: при загрузке формы в браузер вешается плюшка (даже например стандартное и всегда одинаковое nospam=1 поможет во многих случаях), а до обработки формы проверяем наличие плюшки. Это работает потомучто далеко не на всех ботах включены куки. :)
Опираясь на куки или JavaScript конечно надо понимать что мы можем оставить часть пользователей без возможности воспользоваться нашей формой, но тут уже каждый решает сам.
Если код страницы не статичен, а генерируется чем бы то ни было (например PHP), то можно создавать некоторое hidden поле с динамическим именем, а например в сессию ($_SESSION) или в куки (т.к. включать сессии для анонимусов это в каком-то смысле дурной тон) складывать название этого поля (в случае с куками — лучше не название поля, а некоторую функцию от него).
При получении же заполненной формы — проверять значение этого поля на совпадение с некоторым даже стандартным значением — уже поможет.
Т.е. мы не присваиваем некоторое «секретное» значение стандартному полю, а наоборот в неизвестное поле складываем стандартное значение.
Суть метода/принцип работы в том, что боты, которых делают ориентируясь на некоторый «стандартный» движок полагаются на статичные имена полей (делается бот/настройка для бота например только для движка punBB, у которого стандартная форма отправки сообщения) — они не могут обрабатывать такие вещи, как динамические поля, т.к. это просто не предусмотрено. Но не панацея конечно.
Отсюда же следует что даже просто поменяв название полей формы в известном движке мы также избавим ресурс от ботов, умеющих опознавать именно этот движок.
Еще проще: при загрузке формы в браузер вешается плюшка (даже например стандартное и всегда одинаковое nospam=1 поможет во многих случаях), а до обработки формы проверяем наличие плюшки. Это работает потомучто далеко не на всех ботах включены куки. :)
Опираясь на куки или JavaScript конечно надо понимать что мы можем оставить часть пользователей без возможности воспользоваться нашей формой, но тут уже каждый решает сам.
Сама форма полностью создаётся javascript-методом динамчески. Таким образом, форму может увидить лишь пользователь, у которого отработал соответствующий скрипт.
Не знаю писалили до этого, но есть боты использующие браузеры, посему если будет стоять задача разобрать DOM в том же FF, можно повыдирать динамически созданные элементы. Посему если будут точить под конкретный ресурс, то заточат. :)
Можно использовать CSS History Hack для определения того, существует ли у юзера браузер и ходил ли этот юзер по популярным сайтам типа там яху, гугл, яндекс, или одноклассникам каким-нибудь. Правда, всегда остаётся проблема «Как этот факт секурно передать на сервер», но это уже другая задача.
У меня стоит две галки «Я робот» и «Я не робот» нужно отметить только одну
У меня кнопка отправки по-умолчанию в состоянии disabled. При нажатии на checkbox — я не робот — кнопка активируется.
У меня стоит следующий способ защиты:
1. Форма стандартная, без каптчи
2. При генерации страницы создается сессия и записывается в базу
3. Скриптом, каждые 10 секунд идет запрос к определенному скрипту, при этом со стороны сервера проверяются заголовки, то есть отправление должно быть через javascript + сохраняем реферер
4. Проверяется было ли обращение скриптом хоть раз, если же не было тогда в регистрации отказываем
При выполнении всех выполненных выше условий даем пользователю зарегистрироваться, если же нет, то в регистрации отказываем
Если кто-нибудь хочет узнать более подробно как это реализовано пишите мне в личку и при условии, что это будет интересно более 10 человек напишу топик с подробным описанием
С уважением, Сергей
1. Форма стандартная, без каптчи
2. При генерации страницы создается сессия и записывается в базу
3. Скриптом, каждые 10 секунд идет запрос к определенному скрипту, при этом со стороны сервера проверяются заголовки, то есть отправление должно быть через javascript + сохраняем реферер
4. Проверяется было ли обращение скриптом хоть раз, если же не было тогда в регистрации отказываем
При выполнении всех выполненных выше условий даем пользователю зарегистрироваться, если же нет, то в регистрации отказываем
Если кто-нибудь хочет узнать более подробно как это реализовано пишите мне в личку и при условии, что это будет интересно более 10 человек напишу топик с подробным описанием
С уважением, Сергей
Sign up to leave a comment.
Методы защиты веб-формы без капчи