Ich habe ein Service-Setup mit dem CorsFeature und verwende den Ansatz, den mythz in anderen Antworten vorgeschlagen hat, die in einer Funktion gesammelt wurden, die in der appHost-Datei verwendet wird:
%Vor%Der Voranforderungsfilter wird jedoch nur bei einigen der Dienstanforderungen ausgelöst. Eine der Basis-Entitäten, die wir im Service haben, ist eine Frageentität, und es gibt benutzerdefinierte Routen, die wie folgt definiert sind:
%Vor%Wenn wir POSTMAN verwenden, um Testabfragen auszulösen (alle mit dem Verb OPTIONS), können wir sehen, dass dies den Filter vor der Anfrage auslöst:
%Vor%Aber das wird nicht:
%Vor%Vermutlich liegt das daran, dass die zweite und die dritte Route die von ihnen akzeptierten Verben explizit definiert haben, und OPTIONS gehört nicht dazu.
Ist es wirklich notwendig, OPTIONEN in jeder definierten Route zu schreiben, die die unterstützten Verben einschränkt?
Der PreRequestFilters wird nur für gültige Routen ausgelöst, die OPTIONS nicht ausschließt (z. B. indem Verbs=null belassen wird und stattdessen alle Verben behandelt werden - inkl. OPTIONS).
Um alle OPTIONS-Anfragen bearbeiten zu können (dh auch für nicht übereinstimmende Routen), müssten Sie die Anfrage im Beginn der Request-Pipeline (dh bevor die Routen übereinstimmen) mit Config.RawHttpHandlers . Dies geschieht in der CorsFeature für Sie im nächsten Hauptfenster (v4 ) Release von ServiceStack mit:
CustomActionHandler existiert nicht in v3, aber es kann leicht mit:
erstellt werden %Vor%Eine andere Möglichkeit, alle Routen abzugleichen, besteht darin, eine FallbackRoute anzugeben, z. B. um alle Routen zu bearbeiten Sie können der Fallback-Route einen Platzhalter hinzufügen mit:
%Vor%Da es jedoch mit allen nicht behandelten Routen übereinstimmt, gibt es 404 nicht mehr für nicht übereinstimmende Anfragen, da alle nicht übereinstimmenden Routen nun übereinstimmen. Aber Sie können es manuell mit:
leicht handhaben %Vor% Sie müssen nicht das OPTIONS Verb zu allen Routen hinzufügen. Stattdessen können Sie Folgendes tun:
Fügen Sie diese Route einfach Ihrer Question -Klasse hinzu:
Fügen Sie das dann Ihrer Frage-Service-Klasse hinzu:
%Vor% Nun wird jede Route, die mit /question/ beginnt, das OPTIONS Verb unterstützen.
Vielleicht möchten Sie dies einschränken, wenn Sie Subroutinen wie /question/something/ though haben.
Die folgenden Schritte funktionierten für mich innerhalb von ServiceStackV3.
1. Eine neue Klasse CustomActionHandler
hinzugefügt %Vor%2. Fügen Sie den CustomHandler in der AppHostBase.Config.RawHttpHandlers-Auflistung hinzu (diese Anweisungen können in der Configure (Container container) -Methode geschrieben werden).
%Vor%Tags und Links servicestack