* Change semantic of OR of two permission classes
The original semantic of OR is defined as: the request pass either of the two has_permission() check, and pass either of the two has_object_permission() check, which could lead to situations that a request passes has_permission() but fails on has_object_permission() of Permission Class A, fails has_permission() but passes has_object_permission() of Permission Class B, passes the OR permission check. This should not be the desired permission check semantic in applications, because such a request should fail on either Permission Class (on Django object permission) alone, but passes the OR or the two.
My code fix this by changing the semantic so that the request has to pass either class's has_permission() and has_object_permission() to get the Django object permission of the OR check.
* Update rest_framework/permissions.py
* Update setup.cfg
Co-authored-by: Mark Yu <markyu98@outlook.com>
Co-authored-by: Tom Christie <tom@tomchristie.com>
Thanks to Jon Dufresne (@jdufresne) for review.
Co-authored-by: Asif Saif Uddin <auvipy@gmail.com>
Co-authored-by: Rizwan Mansuri <Rizwan@webbyfox.com>
In some cases we end with an operation between two `OperandHolder`.
This didn't work as it didn't knew how to deal with | or &
This fixes by adding those operations.
`x and y` actually returns object y when both are true. the means P & IsAuthenticated will fail with TypeError: unsupported operand type(s) for &: 'instance' and 'bool' as IsAuthenticated now returns a CallableBool which does not overload __ror__
* permissions: Allow permissions to be composed
Implement a system to compose permissions with and / or.
This is performed by returning an `OperationHolder` instance that keeps the
permission classes and type of composition (and / or).
When called it will return a AND/OR instance that will then delegate the
permission check to the operands.
* permissions: Add documentation about composed permissions
* Fix documentation typo in permissions
* Identify code that needs to be pulled out of/removed from compat.py
* Extract modern code from get_names_and_managers in compat.py and remove compat code
* Extract modern code from is_authenticated() in compat.py and remove.
* Extract modern code from is_anonymous() in compat.py and remove
* Extract modern code from get_related_model() from compat.py and remove
* Extract modern code from value_from_object() in compat.py and remove
* Update postgres compat
JSONField now always available.
* Remove DecimalValidator compat
* Remove get_remote_field compat
* Remove template_render compat
Plus isort.
* Remove set_many compat
* Remove include compat
Quietly catching `AttributeError` and `TypeError` when calling
`get_queryset()` is rather insidious, as those exceptions get caught no
matter where they might happen in the call stack.
