Django-tastypie: より安全なデフォルトが必要です： `DjangoAuthorization`はすべてのモデルオブジェクトへの` read`アクセスを許可するべきではありません

これがすでにマージされていることを感謝しますが、私はまだ問題を抱えています。 新しいリクエストを開く前に、ここに私の懸念があります：

この変更により、残念ながら既存のコードが破損するため、下位互換性がなくなります（以前は、すべてのGET要求がDjangoAuthorizationを通過していました）。 コードを修正するには、すべてのユーザーに「変更」権限を与える（悪い）か、読み取りアクションのカスタム実装のためにDjangoAuthorizationをサブクラス化する（多くの作業が必要になる可能性がある）という2つのオプションしかありません。 これは意図されたものですか？

django adminコンテキストでこの背後にある理由に感謝しますが、APIコンテキストで「change」と同等に「read」を設定することは、予期される動作ではないため、賢明なデフォルトの仮定ではありません。 結局のところ、GETがDjangoAuthorizationとともに許可されたメソッドである場合、ユーザーがchange権限を持っていないという事実に基づいて、なぜアクセスを拒否するのでしょうか。

私は彼に次の代替実装を提案します：

_for read_detail_

• モデルにview権限がある場合は、それを確認します（=それを必要とする人のための改善）
• view権限がない場合は、常に許可します（=下位互換性）

_read_list_の場合

• モデルにlist権限がある場合は、それを確認します（=それを必要とする人のための改善）
• list権限がない場合は、常に許可します（=下位互換性）

このようにして、tastypieは、Djangoのパーミッションのデフォルトと互換性のあるデフォルトを追加し、DjangoAuthorizationのカスタム実装を作成する以外に、必要な人にビューとリストのパーミッションを追加することで、改善するための簡単なパスを提供します。

少なくとも、デフォルトの権限を指定する方法があるはずです。

DjangoAuthorization(read_permission='view', # applies to both list, detail if not spec'd
                    read_list_permission='view', # list only
                    read_detail_permission='view') # detail only
# while we're at it, why not add the other permissions too
DjangoAuthorization(change_permission='change',
                    delete_permission='delete',
                    add_permission='add', 
                    # ... add options as per above for each
                    # <action>_<level> permission where 
                    # action is `change,delete,add,read`,  level is `list,detail`)

@SeanHayesが決定します。

ここでの私の意見ですが、デフォルトで読み取りを許可することはセキュリティの問題だったと思います。 生産に非常に近づくまで、私はそれをまったく期待していませんでした。 このコンテキストでは、下位互換性を破る必要があると思います。

あなたの提案では、既存のコードにパラメータパスをDjangoAuthorizationに変更する必要があるように見えます。その場合、クラスを別の名前で呼び出す方が明確だと思います。

read_permission='view'場合を考えてみてください。これが、まさに必要なものかもしれません。 なぜそれが最適ではないのか分かりません

class ModifiedDjangoAuthorization(DjangoAuthorization):
    READ_PERM_CODE = 'view'

他を変更したい場合は、メソッドをオーバーライドするだけです。 変更は実際にそれを非常に簡単にするように設計されました。

class ModifiedDjangoAuthorization(DjangoAuthorization):
    def delete_list(self, object_list, bundle):
        return self.perm_list_checks(bundle.request, 'del', object_list)

    def delete_detail(self, object_list, bundle):
        return self.perm_obj_checks(bundle.request, 'del', bundle.obj)

変更は変更を念頭に置いており、それを簡単にしました。 initparamsとして実行する必要はないと思います。

デフォルトで読み取りを許可することはセキュリティの問題だったと思います。

私は元の問題の意図を疑っていません。 マージされた実装は、言わずに人々の既存のコードと仮定を破り、元に戻すための効率的なオプションがないことを指摘するだけです。

あなたの提案では、DjangoAuthorizationへのパラメータパスを既存のコードに変更する必要があるようです。

私が提案したソリューションをもう一度見てみると、私が提唱しているのは、安全で下位互換性のあるデフォルトのオプションを人々に提供することです。 この場合、ユーザーのコードを変更する必要はありません。

このコンテキストでは、下位互換性を破る必要があると思います。

同意しません。 現在マージされている変更は、下位互換性を損なうだけでなく、GETを許可する必要があるすべてのユーザーに変更許可を割り当てるという明白な方法（現在の実装によって暗示される）という点で、はるかに大きな潜在的なセキュリティ問題をもたらします。

率直に言って、読み取りアクションのchangeアクセス許可がセキュリティをどのように向上させるかはわかりません。同時に、このアクセス許可はPUTも許可します。 異なるアクションの権限を混在させることは良い選択ではないようです。

残念ながら、提案されたModifiedDjangoAuthorizationは、実際にモデルにview権限を追加しない限り、トリックを実行しないため、下位互換性が失われています。 少なくとも、コードを変更する必要があります。そのため、下位互換性を破り、ユーザーにコードベースのやり直しを強制します。

もちろん、オーバーライドは常に特定の要件を達成するためのオプションですが、tastypieの一般的な考え方は、カスタムコードを追加する必要のない賢明で安全なデフォルトを提供することだと思います...

要するに、より良い実装のために、この変更を元に戻す必要があると思います。

change権限は、Django自体から取得されます。 これはDjangoのデフォルトであり、DjangoAdminアプリのセットアップ方法です。 オプションviewはそうではありません。 私は個人的にreadと名付けました。

modelチェックして、どういう意味かわからない。 _metaをチェックすることを意味する場合、それは不完全である可能性があります。 あなたがdbを打つことを意味するならば、私はそれが不必要に高価であるとわかりました。

私の好みでは、あなたが提案したことは、デフォルトの承認には「魔法が多すぎる」側にあるようです。 安全なデフォルトを設定し、簡単に上書きできるようにするだけで十分なようです。 しかし、それは私の意見です。

変更はここに文書化されています： https ：

率直に言って、読み取りアクションの変更アクセス許可がセキュリティをどのように向上させるかはわかりません。同時に、このアクセス許可はPUTも許可します。 異なるアクションの権限を混在させることは良い選択ではないようです。

ユーザーが何かを変更できれば、それを読むことができることを私たちは知っています。それがDjango管理者が行う方法です。

このバージョンは、開発者に自分たちが何をしているのかを考えさせるため、より安全です。 開発者が独自の「読み取り」権限を発明する代わりに、「読み取り」権限のみを持つべきときに、意図的に全員に「変更」権限を与えることを選択した場合、それが問題です。 他の開発者が故意に愚かなことをするのを止めることはできません。私はTastypieが愚かなことをするのを止めるためにここにいます。 この変更のポイントは、開発者が予期しない可能性のある、DjangoAuthorizationを使用するリソースに対するグローバルな読み取りアクセス許可を防ぐことでした。 新しい動作は、開発者がDjango管理者で経験することと一致しています。

古い動作が必要な場合：

1. 0.13.2にアップグレードしないでください。
2. または、 read_list and read_detail`メソッドをオーバーライドします。

ドキュメントが改善される可能性があると思われる場合は、PRを送信してください。

フィードバックに感謝します。 ドキュメントへのリンクをありがとう、十分に公平です、それを見逃してしまったのは残念です（ドキュメントはv0.13.2にあるのに対し、問題はv0.13.4に割り当てられていることに注意してください）。

私のハメ撮りからいくつかの最後の発言をさせてください：

ユーザーが何かを変更できれば、それを読むことができることを私たちは知っています。それがDjango管理者が行う方法です。

Django管理者はchange権限を使用します。これは、管理インターフェースが_changeing_オブジェクトについて_is_であるためです。 そこでは理にかなっています。 定義上、REST APIでのGETリクエストは、_reading / viewing_に関するものです。 ほとんどの開発者は、変更する権限がないためにDjangoAuthorizationが読み取りを拒否することをまったく期待していないと思います。

このバージョンは、開発者に自分たちが何をしているのかを考えさせるため、より安全です。

tastypieが宣伝している機能の1つは、_合理的なデフォルト_を提供することです。 APIのGET（定義：読み取り）メソッドとPUT（変更）メソッドは、すべての意図と目的において異なる操作であり、異なるアクセス許可も必要であると想定するのは非常に合理的ではないでしょうか。

皆さんがそれが価値のある追加だと思うなら、私が書いたものに沿ってPRを提供させていただきます。

変更許可はDjango自体から来ています。 （...）オプションビューはそうではありません。

Djangoにはview permissionを追加するための保留中のPRがあり、それが私がビューを使用した理由です。

デフォルトでは、パブリック/グローバル読み取り操作を許可しません。 それが最後です。 また、現在標準的な方法がない場合に、開発者がどのように権限を設定しているかを推測するつもりはありません。 それを「読む」と「見る」のどちらと呼ぶかさえわかりません。「私はこのようにしています」または「新しいDjangoリリースはそれを別のものと呼んでいます」と言ってここにたくさんの人が来てほしくないです。 。

Djangoがすぐに読み取り/表示権限をサポートしている場合は、それに切り替えます。 今のところ、開発者は、パーミッションを処理するカスタムの方法を処理するために、いくつかのカスタムコードを作成する必要があります。

この問題が解決されたことは知っていますが、チャイムを鳴らして、この変更により、既存のプロジェクトを0.13.xに移行できなくなったと言いたいだけです。

@miraculixxデータを表示するためだけに変更権限を要求するのは少しおかしいという事実に関して、あなたは完全に正しいと思います。 どういうわけか、Djangoのせいにすることができると思いますが、それでも、ビューのアクセス許可の概念がありません（これは私の私のものをまったく別のレベルで吹き飛ばしますが、CRUD管理コンポーネントを含むプロジェクトに単にアクセス許可がないのは非常識だと思いますCRUDのREAD部分）。

本番環境を壊すような変更を加える場合、少なくともそれをバージョン管理に反映できますか？
Tastypieのx.y.zバージョン管理は、ほとんどの人が期待するものと非常によく似

バージョン番号MAJOR.MINOR.PATCHを指定して、以下をインクリメントします。
..
下位互換性のあるバグ修正を行う場合のPATCHバージョン。

新しい本番展開中にこれを追跡するのに非常に不快な時間を費やしました。