0

注文アプリケーションを想定すると、ユーザー「Ben」は次のコマンドを発行して特定の注文をリストできます

/オーダー/1

今..それを行う前に、「Ben」を認証し(ユーザー名/パスワード認証)、ユーザー名をCookieとして送信しました(sha1チェックサムで署名されました)。

httpリクエストごとに、「Bent」がまだ認証されていることを示すCookieを受け取りますが、誰が彼の発行を止めることができますか

/オーダー/23

ここで、id=23 の注文は「Ben」に属していません。

だから私は注文23が実際に「ベン」に属していることを確認するためにいくつかのロジックを書くべきだと思います...それはこの種の状況のベストプラクティスまたはパターンですか?

シリアル主キー ID の代わりに、別の「機能主キー」を使用する必要がありますか?

4

1 に答える 1

0

注文のための合理的な自然な主キーがありません。発見されにくくするために、UUID を使用できます (誤って /orders/4886ed80-dd71-11e0-9572-0800200c9a66 を見つける可能性はかなり低い)...

しかし、それはあいまいさによるセキュリティです。注文の UUID を推測することが不可能な場合でも、トラフィックを盗聴することはできます。また、セキュリティが不明瞭な URL を介してのみ提供されている場合は、Order リソースでやりたいことを何でも行うことができます。

そのような場合、認証をスキップできないことは明らかです。

于 2011-09-12T19:01:07.143 に答える