NotCaptcha for Drupal

23 апреля 2010 в 13:32

Добрый день.

Мы портировали wp-plugin "NotCaptcha Antispam" на Drupal 5.x, 6.x.

Скриншот:

Посмотреть как работает можно вот здесь: http://cloudgears.com/notcaptcha-for-drupal

Хочется критики, замечаний, пожеланий Smile

Комментарии

Master of Tragedy wrote:
А вы на drupal.org выложили?

на форуме разработчиков отписались на предмет критики (http://drupal.org/node/779590)

а в модули еще не выкладывали (если честно, то еще не разбирались даже - у вас есть опыт насколько это просто\трудно опубликовать свой модуль на drupal.org, наверняка там сложный approve процесс)

23 апреля 2010 в 15:07

vgoodvin wrote:
Переведите файлы в кодировку UTF-8.

мы не-ANSI символы не использовали, потому и оставили всё в ANSI...

UTF-8 для друпаловских модулей это рекомендация, хороший стилль или требование drupal.org ?

23 апреля 2010 в 17:48

<a href="mailto:GDI@drupal.org">GDI@drupal.org</a> wrote:
Чтобы разместить модуль на drupal.org надо привести его в соответствие с Drupal coding standards и почитать Module developer's guide. Для проверки соответствия есть специальный модуль Coder.

ок, спасибо

23 апреля 2010 в 20:18

Про utf-8 вопрос есть.

Посмотрели популярные модули (google-analytics, path, views) - они все в ANSI....

В Drupal Coding standards и Module developer's guide про юникод ни слова (кроме как работы со стринговыми функциями)

Вопрос в зал: исходя из каких соображений вы говорите что исходники модуля должны быть в юникоде ?

23 апреля 2010 в 22:23

"cloudgears" wrote:
Посмотрели популярные модули (google-analytics, path, views) - они все в ANSI....

Не знаю чем и что вы смотрели. У меня все UTF-8. Иначе редактор просто не открывает файл и требует явного указания кодировки. Так я и определяю в большинстве случаев в нужной ли кодировке файл или нет. Использую Geany. Я честно не видел официального текста что файлы должны быть в этой кодировке, просто на заре знакомства с этой системой прочитал что Drupal используют ютф, тем самым устраняя проблемы разного рода абракадабры. Загляните в html-код, там всегда . Я принимаю это как хороший тон и избавление от головной боли. Точно также отношусь и к архивам - все в tar.gz, т.к. все модули в нем и одной командой в консоли пользоваться удобнее. Короче решайте сами, ваш модуль, если что перекодировать то дело пары секунд.

24 апреля 2010 в 9:50

"mmc" wrote:
на камод переходи :D, у меня он нормально все открывает ;)

Да меня все устраивает. Все открывает. Но все-равно, спасибо, посмотрю. Когда сидел на винде, тащился от notepad++, после перехода на линукс искал альтернативу, ну и нашел geany.

25 апреля 2010 в 12:53

Спасиб за модуль. Полезная штуковина Smile

«на камод переходи :D, у меня он нормально все открывает ;)»

и за комод )

26 апреля 2010 в 0:20

Если в файле нет кириллических символов, то кодировки UTF-8 и ANSI ни чем не отличаются друг от друга.
А собственно использовать кирилицу (не инглиш) в тексте программ это как раз и есть моветон. Для этого есть локализация.

Исходя из этих двух простых тезисов абсолютно монописуально в какой кодировке сохранены файлы модуля.

Для изучения мат.части: UTF-8

По теме - модуль прикольный, мне понравился.

26 апреля 2010 в 7:43

Спасибо, очень мило и вебдванольно. Жаль только, что не пашет без JavaScript. Очень хотелось бы хоть бы 3 пачки радио-кнопок с картинками для ущербных и бесскриптовых.

26 апреля 2010 в 9:24

Исходя из этих двух простых тезисов абсолютно монописуально в какой кодировке сохранены файлы модуля.

уж лучше бы был чистый русик и переводы не дёргались с базы

26 апреля 2010 в 12:53

Забавная капча.

НО если я все понял верно то:

в текущей ее реализации даже в лоб легко ломаемая.

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

даже не применяя никаких оптимизаций, сейчас перебирая каждую картинку по алгоритму:
повернуть сравнить
будет уходить в среднем 4 секунды на каждую капчу используя оптерон 2Ghz

А если не в лоб то
при более детальном анализе выяснилось что фактически сейчас модуль генерирует только
8 различных хеш сум независимо от картинки.

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

то есть в данной реализации мне даже сравнивать ничего не нужно. просто провести на сайте 10 минут и собрать 8 разных хеш сум. а потом спамить в свое удовольствие.

Как резюме, теоретически модуль можно доработать до состояние когда он действительно начнет выполнять возложенные на него функции.

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

27 апреля 2010 в 17:38

Dеmimurych, так было в старой реализации NotCaptcha, которая под WordPress. В сабжевой реализации под Drupal значения кодируются ключом из настроек плюс случайным IV (Initialization Vector) для текущего набора изображений: http://ru.php.net/manual/en/function.mcrypt-create-iv.php. Так что, по хеш-суммам сравнивать будет проблематично.

Единственный выход - это перебор. Возможно, в будущих версиях появится больше картинок и искажение для улучшения защиты от переборов.

28 апреля 2010 в 7:15

"cloudgears" wrote:
еmimurych, так было в старой реализации NotCaptcha, которая под WordPress.

я смотрел пример расположенный на сайте где опубликован модуль.
точнее по ссылке что там была http://cloudgears.com/comment/reply/3#comment-form

"cloudgears" wrote:
Единственный выход - это перебор. Возможно, в будущих версиях появится больше картинок и искажение для улучшения защиты от переборов.

в будущих версиях, видимо, это капча и станет капчей. А сейчас фиговый листок.

в первую очередь, мне кажется, необходим механизм запрещения получения исходной библиотеки вертикальных изображений.

во вторую искажения приводящие к затруднению сравнения изображений.

самое простое что напрашивается - искажение цветовой схемы, создание шумов и т.д. и .т.п

и помните, по неписанному правилу, капча считается ломаной, если существует алгоритм дающий 30% верных ответов.

28 апреля 2010 в 12:59

Dеmimurych wrote:

я смотрел пример расположенный на сайте где опубликован модуль.
точнее по ссылке что там была http://cloudgears.com/comment/reply/3#comment-form

Dеmimurych, спасибо вам за тестирование нашего модуля. Действительно, неправильно был выбран cipher mode, из-за чего зашифрованные данные получались всегда одинаковыми независимо от initialization vector (IV). Этот баг исправлен в версии 1.0.2, которую вы можете скачать и посмотреть по адресу http://cloudgears.com/notcaptcha-for-drupal.

Информация для любопытствующих:

Quote:

mode is one of the MCRYPT_MODE_modename constants or one of "ecb", "cbc", "cfb", "ofb", "nofb" or "stream". The IV is ignored in ECB mode as this mode does not require it. You will need to have the same IV (think: starting point) both at encryption and decryption stages, otherwise your encryption will fail.

То есть, в режиме ECB у нас вообще игнорируется IV как таковой.

Dеmimurych wrote:

в будущих версиях, видимо, это капча и станет капчей. А сейчас фиговый листок.

в первую очередь, мне кажется, необходим механизм запрещения получения исходной библиотеки вертикальных изображений.

во вторую искажения приводящие к затруднению сравнения изображений.

самое простое что напрашивается - искажение цветовой схемы, создание шумов и т.д. и .т.п

и помните, по неписанному правилу, капча считается ломаной, если существует алгоритм дающий 30% верных ответов.

Вертикальные изображения в версии 1.0.2 защищены файлом .htaccess. По шумам - возможно, в следующей версии. Спасибо за конструктивные предложения Smile

28 апреля 2010 в 16:55

«Единственный выход - это перебор. Возможно, в будущих версиях появится больше картинок и искажение для улучшения защиты от переборов.»

А блокировку после третьей попытки нельзя поставить, например?

28 апреля 2010 в 14:22

"Shift-Web" wrote:
уж лучше бы был чистый русик и переводы не дёргались с базы

Если сайт только русскоязычный, то полностью согласен!

2 мая 2010 в 2:29

"Sinkora" wrote:
Если сайт только русскоязычный, то полностью согласен!

А потом перейдет проект на поддержку третьему лицу в то время как его попросят сделать многоязычность и он долго вас будет вспоминать теплыми русскими словами, мало ли что вы еще придумаете с таким подходом к оптимизации.

За удобство надо платить. В данном случае, за удобство разработки, за уникальность мы платим скоростью. Для увеличения производительности есть кеширование в разных формах. Не нравится, можно делать на чистом HTML, вот где скорость то будет.

2 мая 2010 в 18:20

"Sinkora" wrote:
Если сайт только русскоязычный, то полностью согласен!

"vgoodvin" wrote:

А потом перейдет проект на поддержку третьему лицу в то время как его попросят сделать многоязычность и он долго вас будет вспоминать теплыми русскими словами, мало ли что вы еще придумаете с таким подходом к оптимизации.

  • Во-первых, проектом буду заниматься только я.
  • Во-вторых, многоязычность на сайте 100%-но не планируется.

"vgoodvin" wrote:

За удобство надо платить. В данном случае, за удобство разработки, за уникальность мы платим скоростью.

Скоростью вы больше платите не за уникальность, а за универсальность. Уникальные проекты не делаются конвейером.
Вот хорошее высказывание товарища seaji, которое он написал здесь:
"seaji" wrote:
А вообще, есть два понятия.
Продакшн и девелопмент. По русски: Рабочий вариант и вариант в разработке.
Продакшн лучше всего оптимизировать под производительность, под ваш, конкретный, вариант.
Девелопмент лучше всего оптимизировать под универсальность.
Друпал больше склоняется к универсальности, поэтому здесь свой "плохой тон".
Если Вы уверены, что Ваша разработка на 150% не будет выложена в общий доступ и на всеобщее обозрение, то лучше всего ориентироваться на производительность.
Если же Вы собираетесь делиться этим с сообществом, то уж учитывайте и универсальность.

"vgoodvin" wrote:

Для увеличения производительности есть кеширование в разных формах. Не нравится, можно делать на чистом HTML, вот где скорость то будет.

Систему API кеширования Друпала активно использую. Но! Прежде чем страница, блок, или какой-нибудь другой фрагмент попадут в кеш, они должны сгенерироваться - а это тоже затраты ресурсов!

2 мая 2010 в 18:47

Quote:
Скоростью вы больше платите не за уникальность, а за универсальность. Уникальные проекты не делаются конвейером.

Сто процентов верно. Инкубатор убивает уникальность

2 мая 2010 в 19:21

Спасибо за поправку. Попутал термины.

"Sinkora" wrote:
Во-первых, проектом буду заниматься только я.

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

2 мая 2010 в 20:54

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

3 мая 2010 в 19:34

Шикарная капча. Только у меня проблема. Как сделать картники прозрачными?? а то у меня на блоге они белые и ужасно смотрятся
seobw.ru

6 мая 2010 в 18:02

после включения ноткапчи и вывода ее на страницу регистрации ругается при регистрации

Fatal error: Call to undefined function mcrypt_get_iv_size() in .\www\sites\all\modules\notcaptcha_captcha\notcaptcha_captcha.module on line 586

??

25 мая 2010 в 0:48


Как убрать эти полоски по бокам? Во всех браузерах эти полоски. Этот баг с полосками есть на всех сайтах, где установлена эта капча, независимо от движка, прозрачности и т.д. Полосок не видно только при масштабе 100%.

zsaz, прозрачности удалось добиться, принудительно присвоив переменной цвет фона $background = 0xf3f2ff; и отредактировав в фотошопе gif-ки.

Под вордпресс уже новая версия этой капчи вышла. Может её портировать?

23 сентября 2013 в 3:53