How not to wind rating on Habré

In continuation of the article . Tale about how Habr patched one more way to cheat the rating faster than I could poked on that.

We continue to explore the site API Habrahabr and accidentally find changes in the mechanics of rating calculation.

I want to say from the shore that the article is of an entertaining nature and does not pretend to be scientific.
So, if you are good today, then welcome under cat.

Introduction

Well, Habr, you have imposed a limit of 3 posts per day, but you can’t just forbid flood in the comments. And as we know, every comment is vitamins, proteins and calcium potential 0.1 ratings, which in total give about the same amount as posts.

You might think: "Aah, just spawn comments with pluses and that's it ... Well, it's not interesting," but not here - we'll scoff at the Hubr API and catch funny bugs.

So, for this recipe, we need: one old article, so as not to attract attention, and a verified account of a friend, which we will push into the top.

By the way, despite the fact that the article is old (as much as six months already), it still crawls into the most discussed one:

Fortunately, this is the most discussed thing, far from hanging on the front page, you can not worry.

In essence, we need two requests: to post a comment and approve it.

API

As it turned out, in the request for posting a comment, everything is rather clumsy, but found a strange thing. The parameters in the API for the desktop version and the mobile version are somewhat different.

For example, creating a comment from a regular browser, we send the following request, specifying the value add as action:

But if you do the same thing from the mobile version, which comes with the prefix m. in the way of the site, now the action gets the value of mobile_add:

This solution is a bit surprising, since it is possible to determine the site behavior at the level of mobile-specific headers. Nevertheless, I did not find significant differences in behavior on this basis.

A small digression.
I tried to see how it was done in the habr iOS application, but everything turned out to be extremely serious and SSL Pinning was turned on, which prohibits eavesdropping, which cannot be bypassed even with the help of a fake root certificate:

Now while trying to arrange hara-kiri jailbreak your iPhone to get the opportunity to play with the API through black magic , but this is still in progress. Technically, the API is generally open, there is even a string on a boa and a puff , but without a token issued by the habr, nothing will work. Or just find an Android device, but there also need a witch.

But with the voting all the more interesting.
It turned out that the method of voting for comments and articles in general is the same and differs only in the only parameter responsible for the article in which there is a comment.
Let me remind you the structure for voting for an article:

body = { # id  'ti' => params[:id], 'tt' => 2, 'v' => 1 } 

And this is how the structure of voting for a comment in it looks like:

 body = { #   id  'ti' => params[:id], 'tt' => 3, #    id  'pti' => 322908, 'v' => 1 } 

In my humble opinion, done a little crooked.
The same parameter in the same action has two different purposes. In general, this is one request for two different actions. But it’s not for me to judge Habr, it all works in the end.

And you can calm down, run the script and go to drink tea, but that would be boring.
We will play with the parameters. What if the v field is set to 100? No, writes that the page is not found. Or maybe -100? Same.

In general, habr to any wrong action always returns 404:

Whether it is an error in a parameter or something else. It is impossible to understand whether there really is no page or you were simply sealed somewhere. It’s probably effective against hackers, but was it convenient during the site development process?

And nevertheless at some point Habr freaked out:

It happened when v became zero. I heard something like that in kindergarten from a caregiver when I was throwing bread at lunch.

And if there is still a wrong comment id to indicate, then we will still be scolded:

Of the interesting points, I noticed that the comment number is incremented by 2, not one.
That is, if the first comment comes with the value:

 comment_100002 

then the next one will be

 comment_100004 

I am sure that one more comment could not interpose between them. The situation was stably reproduced over a dozen tests late at night with a split in a split second.
But maybe I'm wrong. If anyone can explain the logic of this phenomenon, then write in the comments.

Mortal sins

But what about without the human factor. This time I decided not to hide and simply rivet comments on my old article, without hiding it in drafts. And this was my fatal mistake.

Someone was so baked on the kind of undeserved advantages that he was not too lazy to go and put minus for each of the 50 (oh my god) comments:

Fortunately or not, by that moment the shop was already covered, I do not have time to score a dozen points. I noticed it only after a full run of the script, going to the profile to enjoy my victory ... but I was only waiting for complete disappointment.

Naturally, I decided not to leave it just like that and headed straight for support with the question of where my rating went, which I had so hard worked out. And that's what they said to me:

Apparently, "not so noticeable" now means "nothing at all."

Seriously, to the direct question of how many comments are now added to the ratings, the support replied: "We are not authorized to disclose this information."

Even when later I independently walked through other people's comments in different articles, leaving the pros and cons to reveal any dependence, nothing happened, unfortunately. Regardless of how many have already voted for a certain comment, a lot or no one at all, my vote could not change the rating of the author.

If you have any information about this, I will be glad to hear.

Conclusion

That's how Habr rapidly cooled my ardor, showing that I was still far from a hacker.

In general, of course, the essence is not in the markup, but in the research of the site. The impression is that in Habré, as elsewhere, there is a multitude of legacy code and solutions left over from the launch of the project that simply makes no sense to redo it.
Next time we will dig in a more serious direction, towards the real API used in the mobile application, which even looks superficially professional.

UPD1: Numbers of comments go through 2 for compatibility with Geektimes: on Habré even, on Geektimes odd. Thanks to lexnekr for the clarification .
UPD2: A special opinion approached about the increment id. It is said that this is due to the MySQL configuration. Thanks youROCK and kafeman for info .
I would be grateful for the proofs if someone can provide them.
UPD3: But I am more impressed with the third opinion: