Django-filter: Filterfelder sind technisch für alle DRF-View-Aktionen erlaubt. Dies bringt das CoreAPI-Schema durcheinander.
Bei Verwendung von CoreAPI mit DRF und aktiviertem DjangoFilterBackend versucht der Client, alle Felder für eine create-, update- oder partial_update-Aktion auch den Abfrageparametern zuzuordnen. Dies unterbricht die Fähigkeit des Clients, diese Methoden zu verwenden.
Beispiel
Wenn wir eine Anfrage haben, die versucht, ein Buch mit einem Namen zu erstellen, und der Name auch ein filterbares Feld in unserem Modell ist:
# book views
class BookViewSet():
filter_fields = ('name',)
# ...
// schema
client.action('book', 'create', { 'name': 'My Awesome Book' });
Dadurch wird eine Anfrage mit dem Namen sowohl im URL-Parameter als auch im Anfragetext erstellt. Dies ist kein erwartetes Verhalten.
POST /api/book?name=My%20Awesome%20Book
name=My Awesome Book
Vorgeschlagene Lösung
Wir haben dies in unserem Code behoben, indem wir stattdessen unser DRF-Filter-Backend auf eine benutzerdefinierte Überschreibung mit dem folgenden Code verweisen:
class OnlyFilterOnReadDjangoFilterBackend(DjangoFilterBackend):
""" A filter backend that only allows for filtering by properties on
actions deemed as safe. This means that create, update, and partial_update
actions will not provide filter options.
"""
SAFE_ACTIONS = ('list', 'retrieve')
def get_schema_fields(self, view):
if view.action in self.SAFE_ACTIONS:
return super().get_schema_fields(view)
return []
Sonictherocketman
Alle 3 Kommentare
Hallo @Sonictherocketman. Danke für den Bericht.
Mein erster Gedanke ist, dass dies ein Fehler in der Client-API ist – es wird beim Erstellen der Anfrage nicht angemessen zwischen Abfragezeichenfolgenparametern und Anfragetext unterschieden.
Im Allgemeinen ist es nicht richtig, nur die Filterung für nicht sichere Aktionen zu deaktivieren. Das Filtern erfolgt beim Einrichten des Basisabfragesatzes, für den eine Aktualisierung durchgeführt wird.
Ich lasse das jetzt offen, nur um darüber nachzudenken.
carltongibson
am 16. Mai 2018
Ich denke auch, dass es sich um ein Client-Problem handelt, aber je mehr ich darüber nachdachte, desto mehr habe ich das Gefühl, dass die Aktionen bei Schreibabfragen (insbesondere beim Schreiben in eine bestimmte Ressource) keinen Sinn ergeben und imo das Schema nicht sollte haben diese Felder, wenn sie nicht verwendet werden sollen.
Danke für die schnelle Antwort und ich bin sehr daran interessiert, was Sie darüber denken.
Sonictherocketman
am 16. Mai 2018
Mehr oder weniger denke ich, dass wir hier durch unseren Wunsch nach _automagischer_ Codegenerierung eingeschränkt sind, die die Technologie (in ihrem aktuellen Zustand) überflügelt.
Es gibt vieles, was wir (noch) nicht mit Schemas (in einem der verfügbaren Formate) tun können, was wir gerne tun würden – zum Beispiel sind wir mit CoreAPI noch nicht in der Lage, Parameter zu gruppieren, damit ein Datumsbereichsfilter angezeigt wird dass sie verwandt sind. (Es gibt noch viel mehr , was wir tun können, indem wir Schemas von Hand schreiben, aber das will natürlich niemand.)
Aber es entwickelt sich weiter, und damit auch die Werkzeuge. Es wird sich verbessern.
Dass diese bestimmte Zeile:
client.action('book', 'create', { 'name': 'My Awesome Book' });
verwendet das gleiche Diktat für beide Abfragezeichenfolgen und der Anforderungstext ist nicht großartig. Ich denke, es ist die Abstraktion undicht. Sie möchten diese Anfrage wirklich _von Hand_ erstellen, indem Sie die Abfrageparameter und den Hauptteil an getrennten Stellen angeben.
Dies ist derzeit nichts, was wir hier ansprechen können. Danke aber nochmal für den Bericht.
carltongibson
am 16. Mai 2018
Verwandte Themen
hakib
·
3Kommentare
edmorley
·
3Kommentare
Alexx-G
·
4Kommentare
loganknecht
·
4Kommentare
inakrin
·
3Kommentare
Hilfreichster Kommentar
Hallo @Sonictherocketman. Danke für den Bericht.
Mein erster Gedanke ist, dass dies ein Fehler in der Client-API ist – es wird beim Erstellen der Anfrage nicht angemessen zwischen Abfragezeichenfolgenparametern und Anfragetext unterschieden.
Im Allgemeinen ist es nicht richtig, nur die Filterung für nicht sichere Aktionen zu deaktivieren. Das Filtern erfolgt beim Einrichten des Basisabfragesatzes, für den eine Aktualisierung durchgeführt wird.
Ich lasse das jetzt offen, nur um darüber nachzudenken.