みなさんこんにちは！ 州による不合理なブロックを含むブロックの成長により、アイデアの説明と特定のパスとドメイン名によるブロックから保護されているサイトの設定のプロトタイプが注目されます。 保護をブロックするためのアイデア：

• アスタリスク付き
• IPで

他の投稿で概説されます。 話題を気にする人は、猫の下に行きます。

リンク

https://github.com/http-abs/http-abs/

アイデアの説明

保護の原則は、各ユーザーが個々の（サブ）ドメインから一意のペアと、サイトを表示するためのパスプレフィックスを受け取ることです。 このペアをエージェント識別子と呼びます 。

これはどのようにブロッキングから保護しますか？

• ロックがパスおよび/または正確なドメインによって制限されている場合、そのようなパスおよび/またはドメインをブロックするアプリケーションを送信することにより、ロックオペレーターは他のユーザーの利益に影響を与えることなく、自身のアクセスのみをブロックします。

• サイト管理者がブロックを見つけた場合、このアドレスで問題のある素材の問題を除外することができます（たとえば、シールで置き換える）。これは、他のユーザーへの同じ素材の配信に影響しません。

• コンテンツのローカル置換により、ロックのリストからリンクを除外しようとする機会が与えられ、たとえばドメイン名による完全なブロックが回避されます。

しかし、リンクを共有する方法は？

簡単です。 サイトを表示するためにユーザーに割り当てられたエージェント識別子は、ユーザーのCookieに保存されます。 ユーザーは、アドレスバーからリンクを共有するだけです。

• ユーザーがまだ対応するCookieを持っていない場合、他の人の識別子を含むリンクをクリックすると、新しいエージェント識別子を割り当てるプロセスが開始され、この識別子を含む個々のマテリアル表示URLへのリダイレクトが行われます。
• ユーザーが既にエージェント識別子を含むCookieを持っている場合、他の誰かの識別子を含むリンクをクリックすると、このユーザーの個別のマテリアル表示URLへのリダイレクトが開始されます。

クッキーを保存する理由

オペレーターロックを分離します。 運がよければ、数回ロックした後でも識別できます。

これはユーザーの生活を複雑にしますか？

文字通り、彼には何も必要ありません。 彼は通常の方法でサイトを訪れ、資料を読み、リンクを共有します。 彼の人生では、アドレスバーの外観のみが変わります。

これはサーバー開発者の生活を複雑にしますか？

おそらく。 エージェント識別子に含まれるパスプレフィックスとサブドメインを考慮する必要はありません。これらは、着信URLの処理の最初の段階でハンドラーによって切断されます。 ただし、プロセスを完全に透過的にするためには、一生懸命働く必要があります。

ロックオペレーターは断熱材をバイパスできますか？

もちろん。 しかし、ルールがさらに複雑なルールに変更される可能性があるという事実にもかかわらず、複雑なルールによって形成されるマテリアルへの無限のリンクをブロックする必要性を証明することは、彼にとってはるかに困難です。

オペレーターは、アスタリスクとIPアドレスですべてを単純にブロックします

このようなイベントの展開は除外されませんが、別の記事でこれらのケースを個別に検討したいと思います。 おそらく一緒に、コメントに追加の何かを思い付くでしょう。

実装

建築

プロセスを可能な限り透過的にするために、コードはnginx



フロントエンドサーバーに集中しています。 これにより、実質的に制限なしに、さまざまなアプリケーションサーバーを保護できます。

リクエストの処理は非常に重要なので、追加のパッケージlibnginx-mod-http-lua



を使用しました。これは、nginxでリクエストを処理するプロセスでlua



言語を実装します。

追加条件

理想的には、バックエンド（アップリンク、アプリケーションサーバー）が保護下にあるかどうかについてまったく気にしないように処理を行う必要があります。 彼はリクエストをURLで受け取り、そこからエージェント識別子のすべての要素が削除されます（そのような純粋なURLを呼び出しましょう）。 返されたページをやり直さないために、エージェントID Cookieが設定されたクリーンなURLをクリックすると、個々のURLにリダイレクトされます。

フロントエンドは、エージェント識別子Cookieを除き、状態を保存しません。

ブラウザにはJavaScriptコードの行は含まれていません。 HTTPプロトコルのみが使用されます。

アルファ実装の制限

実際、概念実証のみが実装されているため、アルゴリズムの実際の動作を観察できます。 製品のパッケージングに関連する多くの部品が決定されていません：モジュール性、パラメーターの分離と検証など。

サブドメインの場合、追加のDNSサーバーをインストールせずに、 hosts



と組み合わせて使用​​するのに適した、固定されたサブドメインのセットを持つスキームが選択されます。

パスプレフィックス形式は事前定義されており、16進数で32桁です。

インストールされた起動オプション

これまでのところ、起動パラメーターはコード内で設定されています。

サブドメインのセット（a、b、c）は変数に設定され、拡張できます。

ドメインはexample.com



として設定されexample.com



。

バックエンドは、 http：//127.0.0.1：8000の時点で期待されています

結論

突然の妨害の脅威が高まり、事前に準備し、完全に忠実なサイトの所有者でさえもそれらから保護する方法を発明しなければなりません。 このような保護は非常に可能であり、ユーザー側でのジェスチャーを必要とせず、サイト管理者がかなりの労力で実装できます。