2

私は初心者で、次のことをしたいです

次のようなサービスエンドポイントがあります 

@login_required
@app.route('/')
def home():
  pass

@login_required
@app.route('/add')
def add():
  pass

@login_required
@app.route('/save')
def save():
  pass

@login_required
@app.route('/delete')
def delete():
  pass
  • これらの呼び出しを行うときに、ユーザーからユーザーへの認証を希望します。
    質問
  • Python を使用して REST 呼び出しを認証するにはどうすればよいですか?
  • コールがエンドポイントのいずれかを実行するために着地した場合、それらが認証されていることを確認するにはどうすればよいですか?
  • 将来 (Amazon S3 のように) より適切にスケーリングできるように、状態を保存せずに HTTP ヘッダー レベルで基本的にすべての認証を行うにはどうすればよいでしょうか。

私はRESTの世界にまったく慣れていないので、これを達成する方法が本当にわかりません。

ありがとうございました

4

3 に答える 3

2

まず、質問です。ユーザー、クライアント、またはその両方を認証していますか?

クライアントの認証には、REST サービス認証用のHTTP MAC 認証が気に入っています。Mozilla Servicesのmacauthlibと、それがpyramid_macauth プロジェクトでどのように使用されているかを調べてください。サービスを保護するために macauthlib を適用する例として、pyramid_macauth から学ぶことができるはずです。他の誰かが Flask でこれを試したかどうかを検索することも良い考えです。

ユーザーとクライアントの認証については、適切な OAuth 2.0 を参照してください (HTTP MAC Auth は関連する仕様です)。

もっと多くのリンクを投稿したいと思っていましたが、これは私の最初の投稿であり、応答でより多くのリンクを獲得する必要があるようです. :)

于 2013-03-06T18:17:49.133 に答える
1

セキュリティは初心者向けではありません。フレームワークを使用し、その実装に依存します。ソース コードを調べ、ブログや論文を読むと、ある時点で独自のシステムを構築できるようになります。

失敗する可能性のあることはたくさんあります。一度プロトコルを展開すると、既存のクライアントを壊さずに元に戻すことができない場合があります。

とはいえ、リクエストを認証する通常の方法は、通常は公開鍵と秘密 (秘密) 鍵と呼ばれる 2 つのトークンを使用することです。亜種は、秘密鍵を使用して短命のセッション トークンを生成します。別のバリアントは、クライアントごとに固有の API キーを使用しています。とにかく、このトークンは通常、HTTP ヘッダー (標準の Cookie またはカスタム Cookie) で送信されますが、リクエスト本文を使用することもできます。シークレットはログ ファイルで終わる可能性があるため、通常は URL に追加されません。また、秘密鍵の保管方法と保管場所にも注意を払う必要があります。

チャネル (プレーン HTTP) によっては、シークレットをそのまま送信する代わりに、HMAC を使用してリクエストに署名することをお勧めします。リプレイ攻撃に注意する必要があります。タイミングアタックが可能。暗号衝突を使用して、スキームを無効にすることができます。CSRF を回避するためにトークンが必要になる場合があります (Web ブラウザーが機能しない場合、これは実際には必要ありませんが、これを指定しません)。

繰り返しますが、フレームワークを選択し、自分で何もコーディングしないでください。通常、壊れたソフトウェアは修正できますが、セキュリティ ホールは実際に損害を与える可能性があります。

于 2013-03-06T14:25:10.903 に答える
0

APIを見ると、安らかなエンドポイントのようには見えません。URIは、アクションではなく特定のエンティティを表す必要があります。たとえば、ユーザーなどのエンティティを扱っている場合は、yourdomain.com / userを使用して、POST、DELETE、PATCH、GETなどのHTTP動詞を使用して、作成、削除、更新、フェッチなどのさまざまな操作を実行できます。フラスコこれは非常に簡単に達成できます）。

セキュリティの観点から、複数のスキームがあると思いますが、私が使用したものは、最初の認証呼び出しを介してキーとシークレットを指定してセッショントークンを生成することです。キーとシークレットのペア、およびセッショントークンの生成に関する専門のオンラインリソースを探すことをお勧めします。

スケーリングに関しては、セッションが特定のマシンに固有であってはならないという懸念があると思います。認証データは、HTTPフロントエンドとは別にストアに保存できます。このようにして、Webサーバーを追加してフロントエンドを拡張したり、データストアを追加して必要に応じて拡張したりできます。

于 2013-03-06T14:35:10.077 に答える