Pull to refresh

Как НЕ накрутить рейтинг на Хабре

Reading time 4 min
Views 10K


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


Продолжаем исследовать сайтовый API Habrahabr и случайно находим изменения в механике начисления рейтинга.


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



Вступление


Хорошо, Хабр, ты ввел ограничение на 3 поста в день, но ты не можешь просто так запретить флуд в комментах. А как мы знаем, каждый комментарий — это витамины, белки и кальций потенциальные 0.1 рейтинга, которые в сумме дают примерно тот же объем, что и посты.


Вы могли подумать: 'Ааа, просто наплодить комментов с плюсиками и все… Ну так не интересно', а вот и нет — мы еще будем издеваться над API хабра и ловить веселые ошибки.


Итак, для этого рецепта нам потребуются: одна старая статья, чтобы не привлекать внимания, и проверенный аккаунт друга, которого будем толкать в топ.


Кстати, несмотря на то, что статья старая (аж полгода как), в самое обсуждаемое она все равно пролезает:


К счастью, это 'самое обсуждаемое', далеко не на фронт-пейдже висит, можно не переживать.


По сути, нам нужно два запроса: для размещения комментария и его одобрения.


API


Как оказалось, в запросе на размещение комментария все довольно-таки топорно, но нашел странную вещь. Параметры в API для десктопной версии и мобильной несколько различаются.


Например, создавая комментарий из обычного браузера, мы отправляем следующий запрос, указывая в качестве action значение add:

Но если тоже самое делать из мобильной версии, которая идет с префиксом m. в пути сайта, то теперь action приобретает значение mobile_add:

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


Небольшое отступление.
Пытался посмотреть как сделано в iOS приложении хабра, но там оказалось все крайне серьезно и включен SSL Pinning, запрещающий подслушивание, который никак не обойти даже с помощью подложного root сертификата:

Сейчас пока пробую устроить харакири jailbreak своему айфону, чтобы получить возможность поиграться с API посредством черной магии, но это пока в процессе. Технически API вообще-то открыто, есть даже либа на удаве и пыхе, но без token-а, выдаваемого хабром, ничего не получится. Либо просто найду Android устройство, но там тоже нужно колдунство.


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


body = {
# id статьи
    'ti' => params[:id],
    'tt' => 2,
    'v' => 1
}

А вот как выглядит структура голосования за комментарий в ней:


body = {
# теперь это id комментария
    'ti' => params[:id],
    'tt' => 3,
# а вот это id статьи
    'pti' => 322908,
    'v' => 1
}

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


И уже можно успокоиться, запустить скрипт и пойти пить чай, но это же было бы скучно.
Будем играться с параметрами. Что если полю v поставить значение 100? Нет, пишет, что страница не найдена. А может -100? Тоже самое.


Вообще, habr на любое неправильное действие всегда возвращает 404:

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


И все-таки в определенный момент хабр психанул:

Случилось это, когда v стало равно нулю. Я что-то такое в детском садике от воспитателя слышал, когда кидался хлебом на обеде.


И если при этом еще неправильный id комментария указать, то нас еще пожурят:


Из интересных моментов заметил, что номер комментария инкрементируется по 2, а не по единице.
То есть, если первый коммент идет со значением:


comment_100002

то следующий уже будет


comment_100004

Уверен, что между ними не мог вклиниться еще один комментарий. Ситуация стабильно воспроизводилась на протяжении десятка тестов глубокой ночью с перерывом в долю секунды.
Но может, я и ошибаюсь. Если кто может объяснить логику этого феномена, то напишите в комментариях.


Смертные грехи


Но как же без человеческого фактора. В этот раз я решил не скрываться и просто наклепать комментариев к своей старой статье, не пряча ее в черновики. И в этом была моя роковая ошибка.


У кого-то настолько запеклось от вида незаслуженных плюсов, что он не поленился пройтись и для каждого из 50(oh my god) комментариев поставить минус:


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


Естественно, я решил это просто так не оставлять и направился прямиком в саппорт c вопросом, куда делся мой рейтинг, который я так усердно накручивал. И вот что мне ответили:


Судя по всему, 'не столь ощутимо' теперь означает 'вообще никак'.


Если серьезно, то на прямой вопрос о том, сколько теперь привносят рейтинга комментарии, саппорт ответил: 'Мы не уполномочены разглашать данную информацию'.


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


Если у вас есть какая-либо информация об этом, то буду рад услышать.


Заключение


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


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


UPD1: Номера комментариев идут через 2 для совместимости с Geektimes: на Хабре четные, на Geektimes нечетные. Спасибо lexnekr за пояснение.
UPD2: Подъехало особое мнение насчет инкремента id. Говорят, что это обусловлено конфигурацией MySQL. Спасибо youROCK и kafeman за инфу.
Буду благодарен за пруфы, если кто-то может их предоставить.
UPD3: Но мне больше импонирует третье мнение:

Tags:
Hubs:
If this publication inspired you and you want to support the author, do not hesitate to click on the button
+52
Comments 43
Comments Comments 43

Articles