記事を続ける。 Habrがどのようにパッチを当てて、スヌープする時間よりも速くレーティングを上げる方法の物語。
Habrahabr WebサイトAPIを引き続き調査し、誤って評価の割り当ての仕組みの変更を見つけます。
岸辺から、私はこの記事が本質的に面白いものであり、科学的であると主張していないと言いたい。
あなたが今日親切なら、猫へようこそ。
エントリー
Habrさん、1日に3件の投稿という制限を導入しましたが、コメントで洪水を禁止することはできません。 そして、私たちが知っているように、すべてのコメントは ビタミン、タンパク質、カルシウム 潜在的に0.1の評価で、合計で投稿とほぼ同じボリュームになります。
「ああ、プラスでコメントをすればそれだけです...それでおもしろくない」と思うかもしれませんが、いや、HabrのAPIをあざ笑い、面白いエラーをキャッチします。
したがって、このレシピには、注目を集めないようにするための1つの古い記事と、トップにプッシュする友人の検証済みアカウントが必要です。
ちなみに、この記事は古い（6か月）という事実にもかかわらず、依然として最も議論されている記事に忍び込んでいます。
幸いなことに、これは「最も話題になっている」ものであり、フロントページにぶら下がっていることにはほど遠いので、心配する必要はありません。
実際、コメントの投稿と承認の2つのリクエストが必要です。
API
結局のところ、コメントを投稿するリクエストではすべてが不器用でしたが、奇妙なことがわかりました。 デスクトップバージョンとモバイルのAPIのパラメーターはわずかに異なります。
たとえば、通常のブラウザからコメントを作成する場合、アクションとしてaddを指定して次のリクエストを送信します。
ただし、接頭辞mが付いたモバイルバージョンから同じことを行う場合。 サイトのパスで、アクションは値mobile_addを取ります：
このソリューションは、モバイルバージョンに固有のヘッダーレベルでサイトの動作を判断できるため、少し驚くべきものです。 それにもかかわらず、私はこれに基づいて行動に大きな違いを見つけませんでした。
小さな余談。
ハーバーのiOSアプリケーションがどのように行われたかを確認しようとしましたが、すべてが非常に深刻であることが判明し、SSLピンニングがオンになりました。
今、私は手配しようとしています ハラキリ iPhoneをジェイルブレイクして、 ブラックマジックでAPIを試してみる機会を得ますが、これはまだ進行中です。 技術的には、APIは一般にオープンであり、 boaとpuffにboaさえありますが、hubrによって発行されたトークンがないと、何も機能しません。 または、Androidデバイスを見つけますが、そこには魔術も必要です。
しかし、投票では、すべてがすでに興味深いものになっています。
コメントと記事の投票方法は一般的に同じであり、コメントが配置されている記事を担当する唯一のパラメーターのみが異なることが判明しました。
記事の投票構造を思い出させてください：
body = { # id 'ti' => params[:id], 'tt' => 2, 'v' => 1 }
そして、コメントの投票構造は次のようになります。
body = { # id 'ti' => params[:id], 'tt' => 3, # id 'pti' => 322908, 'v' => 1 }
私の謙虚な意見では、少し曲がった。
同じアクションの同じパラメーターには2つの異なる目的があります。 一般に、これは2つの異なるアクションに対する1つのリクエストです。 しかし、Habrを判断することは私にとってではありません。これらすべてが最終的に機能します。
落ち着いてスクリプトを実行し、お茶を飲むこともできますが、それは退屈です。
パラメーターで遊んでみましょう。 vが 100に設定されている場合はどうなりますか？ いいえ、彼はページが見つからなかったと書いています。 それとも-100ですか？ 同じこと。
一般に、habrは不正なアクションに対して常に404を返します。
それはパラメータエラーか何か他のものです。 本当にページがないのか、どこかに封印しただけなのか理解できません。 これはおそらくハッカーに対して効果的ですが、サイトを開発する過程で便利でしたか？
それでも、ある時点で、Habrのフリークアウト：
これは、 vがゼロになったときに起こりました。 夕食時にパンを投げたとき、幼稚園の先生から何かを聞きました。
そして、同時に間違ったコメントidを指定すると、scられます：
興味深い点として、コメント番号が1ではなく2ずつ増加することに気付きました。
つまり、最初のコメントに値が含まれている場合：
comment_100002
その後、次のものはすでに
comment_100004
別のコメントがそれらの間をくさびることはできなかったと確信しています。 この状況は、一瞬の休憩で夜遅くまで十数回のテストで安定して再現されました。
しかし、多分私は間違っています。 誰かがこの現象の論理を説明できるなら、コメントに書いてください。
大罪
しかし、人的要因についてはどうでしょう。 今回は、下書きコピーに隠すことなく、古い記事にコメントを隠さずにリベットすることにしました。 そしてそれは私の致命的な間違いでした。
誰かがそのような不当な利点に動揺しているので、彼は50の （ああ、なんてこった）コメントのそれぞれにマイナスをかけるのが面倒ではありませんでした。
幸いなことに、その時までに店はすでに閉まっていたので、私は数十ポイントを獲得することさえできませんでした。 私は、スクリプトを完全に実行し、勝利を楽しむためにプロファイルに入った後にのみこれに気付きました...しかし、完全な失望だけが私を待っていました。
当然のことながら、私はそれをそのままにしないことに決め、私の評価がどこに行くのかという質問に真っ向から対応しました。 そして、これは彼らが私に答えたものです：
どうやら、「それほど具体的ではない」とは、「まったくない」ことを意味します。
真剣に、コメントが現在どの程度貢献しているかを直接尋ねられたとき、サポートは答えました：「この情報を開示する権限がありません。」
後で別の記事で他の人のコメントを見て回って、賛否両論を残してあらゆる中毒を明らかにしたとしても、残念ながら何も起こりませんでした。 すでに特定のコメントに投票した人が何人いても、多くの人が投票したとしても、誰も投票しなかったとしても、著者の評価を変更することはできませんでした。
これに関する情報があれば、喜んでお聞きします。
おわりに
それでハバーは私の熱意を急速に冷やし、私がまだハッカーから遠く離れていることを示しました。
通常、ポイントはマークアップではなく、サイトの調査にあります。 Habréには、他の場所と同様に、プロジェクトの最初から多くのレガシーコードとソリューションが残っているという印象がありましたが、これは単にやり直すのは意味がありません。
次回は、モバイルアプリケーションで使用される実際のAPIに向けて、より深刻な方向で掘り下げます。
UPD1：Geektimesとの互換性のためにコメント番号は2を通過します：Habrで偶数、Geektimesで奇数。 lexnekrに説明をありがとう。
UPD2：増分IDについての意見が高まりました。 これは、MySQLの構成によるものと言われています。 youROCKとkafemanの情報に感謝します。
誰かがそれらを提供できれば、その証拠に感謝します。
UPD3：しかし、私は3番目の意見にもっと感銘を受けました。
