Pull to refresh
13
0
foff4ik @foff4ik

User

Send message
У меня такого плана аппарат валяется (ч-з месяц перестал почему-то заряжаться) до того если на юзабилити забить вполне работал.
запоздало отпишусь:
Ноуты:
еее Убунта + делл Linux Mint, рабочий тоже Убунта
У жены
Вин ХР, на рабочем убунта.
Стационарный комп под ВинХР (по просьбе жены, раньше тоже под убунтой был)

Нет дома раздаю через системник с Красной шапкой(ухе не помню какой. Ибо рабоает, ну и ладно)
Предостережение самизнаете о чем.
И в шапке еще заменить на «Логин Пользователя»
Ну и кто помешает спамеру заменить мою флешку на свою без персистент-объекта? И использовать хоть 1000 паралельных запросов?
Ага, а эцп будет выдавать «паспортный стол» по месту жительства после предоставления справки о несудимости, и сведений о прописке из жека, а также характеристикой от соседей. :)
А их продать для книжки занимательные задачки :)
здесь какраз суть в том что капчу он получит только решив задачу.
Выше я уже обьяснил почему задержка выдачи капчи не сработает.

Тут тоже самое только паузу будет делать не сервер а клиент.
С прямыми не понял, если там «не» лишние то это делается так навскидку:
просматриваем окружность около всех точек на вопрос смены цвета если смен >=8 то пересечение. Может есть и более легкие методы.

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

К тому же суть идеи только коственно касается сложности подбора а более для противодействию нагрузке при подборе с слабой вероятностью распознавания.
в данном случае мне ответить нечего :) тут вы правы, но конечно не думаю что настолько все плохо, раз в 5 еще ладно но на 2-3 порядка :/ не очень верится, может только задачу подобрать которая будет выполнятся одинаково независимо от языка… (но по этому поводу никаких мыслей по крайней мере пока у меня нет)
Напомнило советы програмках: «А знаете ли вы ?»
Брутфорс в данном случае приведен только для примера программы нагружающей клиента, вместо него может быть любая задача результат выполнения которой мы знаем, а для получения ответа клиентом нужно некоторое время работы его компьютера,

По поводу необращения внимания ботов на маленькие сайты, приведу пример: Года 3 назад пытался сделать развлекалку типа фишек, посещалка была в среднем примерно 500 человеков/день, потом туда был поставлен форум(ipb кажется), на котором по прошествии месяца, в день регистрировалось по 20-50 ботов.

Но вы правы, конечно, иногда сложность регистрации не соответствует нужности регистрации на сайте. Каждый для себя выбирает методы согласно своих потребностей, а я только предложил один из них.
Спасибо, поправил :)
Дело в том что этим мы не уберем загрузку а только отсрочим ее, т.е. например:

Клиент посылает 100 запросов сначала, потом за время пока ждет капчу по первым 100 запросам делает еще 1000 в итоге мы получаем ту же нагрузку но осроченую на время ожидания капчи.
По поводу нагрузки я уже выше отписался(предупреждать, и начинать считать перед заполнением формы),

по поводу ограничений на время выполнения это да, но думаю можно это как-нибудь обойти,

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

Но конечно я могу быть некомпетентен в некоторых технических аспектах, и возможно вы правы.
Вобщем я так подумал что пользователь сталкивается с данным вопросом чаще всего только при регистрации, а следовательно пока он дойдет до ввода капчи ему еще приходится заполнить несколько полей на что уйдет некоторое время, из чего следует что разница между 5-ю и 20-ю секундами работы скрипта на разных клиентских машинах не оч. существенна.
К тому же можно по небольшому заданию рассчитать сколько времени уйдет на все задание и информировать об этом пользователя.
Ну с этим уже да, сильно не поборешся :)
Хотя на досуге подумать надо будет, но в принципе уже в данном методе ДРС не сможет одновременно распознавать несколько капч => упадет производительнось => поднимется стоимость ДРС что приведет к их нерентабельности. (это в идеале)
ну так ведь прокси в наше время найти не проблема в любых количествах.
Думаю вместо этого действительно бы лучше было накидать примеров, я например тоже на PHP писал, а в ООП по человечески досихпор не разобрался, собственно я поддерживаю автора, хотя и подкинуть ему что-нибудь нужное не могу. Если кто подкинет годной информации буду очень благодарен.

Information

Rating
Does not participate
Location
Киевская обл., Украина
Date of birth
Registered
Activity