1日1スキル: 分散システム向けの低コストの権限検証メカニズム

Weiwen Codeをよくフォローしている人は、私がニュースWebページのテキストを自動的に抽出できるGNE[1]と呼ばれるオープンソースプロジェクトを作成したことをご存知でしょう。その効果は、市場にある他のオープンソースのニュース抽出ツールよりもはるかに優れています。

GNE には GnePro と呼ばれる高度なバージョンもあることをご存知ないかもしれません。 URLを入力するとニュースのテキストを自動的に抽出することができ、GNEよりも多くのフィールドを抽出します。 8 か国 130,000 の Web サイトでテストされ、認識精度は 100% です。

GnePro は、K8S を使用して構築されたクローラークラスターです。背後には数十台のサーバーがあり、ゲートウェイを通じて負荷分散が行われます。 GnePro の権限メカニズムを設計する際には、できるだけシンプルにして、サードパーティのコンポーネントに依存しないようにしたいと考えています。

従来の権限検証メカニズムは一般的に次のようになります: ユーザーがログインすると、Cookie に SessionId が存在します。ユーザーがデータを照会する場合、バックエンドへのリクエストが開始されます。バックエンドはリクエストから SessionId を取得し、Redis またはその他のデータベース内のユーザーのセッションを照会します。セッションには、ユーザーのログイン情報や権限情報などが保存されます。次に、この権限情報に基づいて、ユーザーが権限を持つコンテンツを返します。

ただし、この方法では、Redis などのデータベースを追加で導入する必要があります。そうすると、データの同期、同時実行の競合などの問題に直面することになります。

私のニーズはシンプルです。ユーザーのアカウントの有効期限がいつ切れるか、またそのユーザーがどのレベルにいるのかを知る必要があります。 V1 レベルでは、ニュースのテキスト、タイトル、リリース時間、作成者、画像のみを返すことができます。 V2 は V1 に基づいて、パンくずリスト、SEO データ、Web ページタグを返すこともでき、JavaScript レンダリングもサポートします。 V3 は、Web ページ本体のクリーンなソースコードを返すこともでき、ユーザーが解析用に HTML をアップロードすることもサポートします。したがって、Session を使用する代わりに、JWT を使用して実装します。

この場合、JWT の使用が非常に適しています。 JWT ではサードパーティコンポーネントの導入は必要ありません。どのサーバーでも独立して権限検証を実行できます。

たとえば、ユーザーの現在のレベルと認証の有効期限を示すデータ構造を定義します。

 user_info = { 'level': 'v2', 'expire': '2023-12-01 00:00:00', 'name': '青南' }

Python では、PyJWT を使用して JWT トークンを簡単に生成できます。まず、pip を使用して PyJWT をインストールします。

 python3 -m pip install pyjwt

次に、3 行のコードでトークンを生成します。

 import jwt user_info = { 'level': 'v1', 'expire': '2023-12-01 00:00:00', 'name': '青南' } password = '青南工资9999999999' token = jwt.encode(user_info, password, algorithm='HS256') print(token)

次の図に示すように:

写真

クローラーを頻繁に書く生徒は、eyJh で始まる文字列に馴染みがあるかもしれません。多くのウェブサイトでは、ヘッダーにこのようなトークンが含まれています。

ユーザーがメンバーシップを再チャージすると、トークンを生成してユーザーに送信します。 GnePro を使用してリクエストを行う場合、このトークンをヘッダーに配置するだけです。

バックエンドがリクエストを受信した後、現在どのサーバー上にあるかに関係なく、ユーザーの権限情報を解析するには次のコード行を実行するだけです。

 import jwt token = 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsZXZlbCI6InYxIiwiZXhwaXJlIjoiMjAyMy0xMi0wMSAwMDowMDowMCIsIm5hbWUiOiJcdTk3NTJcdTUzNTcifQ.8xEkWL1pbtHKMXjrVsTtiY4JZnSMf--ufK3fiDp67SY' password = '青南工资9999999999' user_info = jwt.decode(token, password, algorithms=['HS256']) print(user_info)

実行効果は以下の図に示されています。

写真

このJWTトークンはパスワードのように長い文字列のように見えますが、実際には次の図に示すように、Jwt.io[2] Webサイトを直接使用して解析できることに注意してください。

写真

JWT トークンを解析するためにパスワードは必要ありません。ただし、JWT トークンを生成/変更するにはパスワードが必要です。パスワードが間違っている場合は、別の JWT トークンが生成されます。

写真

このトークンは先ほど生成したものと非常に似ていますが、パスワードが間違っているため、検証するとエラーが報告されます。

写真

したがって、このトークンを生成した後、ユーザーがレベルを v3 に変更することを心配する必要はありません。彼は私のパスワードを持っていないので、彼が生成したトークンはここでの検証に合格できません。トークンが改ざんされたかどうかを知ることができます。

検証プロセス全体に必要なのは数行のコードのみで、サードパーティのコンポーネントは必要ありません。少ないほど良いという原則にぴったりです。

もちろん、JWT はセッションを完全に置き換えることはできません。セッションはユーザーの権限と動作をリアルタイムで制御できるためです。たとえば、Web サイトでシングルサインオンを実装する場合、ユーザーがブラウザー A からログインすると、ブラウザー B から自動的にログアウトされます。この機能は、JWT のみを使用して実現することはできません。

JWT 情報に SessionId を追加すればいいのでは、と言う人もいるかもしれません。バックエンドが SessionId に対応する情報を読み取ると、さらに多くの操作を実行できるようになります。

しかし、これを行うことと、SessionId を Cookies に直接配置することの違いは何でしょうか? JWT はもともと軽量な権限検証に使用されます。独自のシーンがあります。セッションである必要はありません。 JWT をセッションとして使用しないでください。