Ich entwickle eine Angular 2-Anwendung auf einem Play Framework 2.5 (Java) Back-End. Wenn ich über die Browser-URL auf meine Endpunkte zugreife, funktionieren sie einwandfrei. Der Aufruf von der Angular 2-Anwendung zeigt jedoch den Fehler:
XMLHttpRequest kann localhost: 9000 / app / myendpoint nicht laden. Nein Der Header 'Access-Control-Allow-Origin' ist auf dem angeforderten Header vorhanden Ressource. Herkunft 'localhost: 3000' ist daher nicht erlaubt Zugriff. Die Antwort hatte den HTTP-Statuscode 500.
Ich habe versucht, der Dokumentation zu folgen und den Filter zu erstellen:
In der application.conf:
%Vor%Filter:
%Vor%In build.sbt:
%Vor%Kennt jemand die wahre Lösung? Danke:)
Arbeitscode:
Filters.java (auf der Projektwurzel)
%Vor%In der application.conf:
%Vor%In build.sbt:
%Vor%Danke euch allen! :)
Ich erinnere mich daran, dass ich das gleiche Importproblem hatte, da ich denke, dass es einige Änderungen bei den Filtern in Play irgendwo um 2.5.0 gab. Und DefaultHttpFilters wurde während des Refactorings durch HttpFilters ersetzt.
Überprüfen Sie den Quellcode auf den korrekten Pfad zu HttpFilters . Wählen Sie das richtige Tag für die Version von Play, die Sie verwenden, und durchsuchen Sie den Quellbaum, bis Sie HttpFilters gefunden haben, und überprüfen Sie das Paket. Dies ist der Pfad für die Java-API für v 2.5.0 .
In Ihrem Post scheint es, dass Sie die Java-API verwenden, aber den Import für die Scala-Version verwenden.
Die Importe für Play 2.5.0 sind: -
Scala - import play.api.http.HttpFilters
Java - import play.http.HttpFilters
Ich benutze Play 2.5.0 (Scala though - nicht Java) und dieser Import funktioniert gut für mich: -
Nach dem, was du gepostet hast, solltest du versuchen, deinen problematischen Import zu ändern: -
%Vor% Ich nehme auch an, dass Sie das Paket für Ihre Filters.java -Datei konfiguriert haben, wenn Sie es nicht im Root-Paket abgelegt haben.
Dies ist der Eintrag in meinem application.conf , da ich package filters anstelle des Standardpakets verwende.: -
Die beste Vorgehensweise besteht darin, sowohl den statischen Kontext als auch den Webservice von einem einzelnen Ursprung aus zu bedienen. Für eine einzelne Domäne ist beispielsweise jeder URI außer / api / * dazu gedacht, statischen Inhalt zu liefern, und / api / * ist ein Reverse-Proxy für die Java-App. Sie sind möglicherweise speziell an Grunt interessiert. Nginx und Apache könnten auch funktionieren.
Zum Beispiel geben Sie in nginx die folgende Konfiguration an:
%Vor%Und dann führen Sie Ihre Java-App auf localhost auf Port 9000 aus. Sie können Ihren gesamten statischen Inhalt an den nach "root" angegebenen Speicherort kopieren und von nginx bereitgestellt bekommen. Sie senden alle REST-Anforderungen an / api / method / name
Der Vorteil dieser Lösung ist solide Sicherheit und die Fähigkeit, SSL einfach zu konfigurieren.
Wenn nur für Entwicklungszwecke gilt, können Sie versuchen, mit einem Browser-Plugin zu verhindern, dass CORS prüft:
Zum Beispiel überall in Firefox oder Allow-Control-Allow-Origin in Chrome.
In der Produktionsumgebung müssen Sie JS-Assets und -Dienste vom selben Host aus bereitstellen oder den Acces-Control-Allow-Origin-Header mit dem spezifischen Wert für Ihre Services festlegen.
Sie zeigen nicht viel von Ihrem Projekt, so dass es schwer zu verstehen ist, was für ein Problem es sein könnte. Ich glaube nicht, dass es hier ein CORS-Problem gibt, da standardmäßig keine Sicherheitsfilter aktiv sind. Sie können hier finden, wie Sie angular und Play integrieren können.
Im Interesse anderer, die mit dem Front-End- und Lagom-Backend-Projekt Angular 4 arbeiten. Ich habe es geschafft, diesen Weg zu lösen.
* Ich habe diese Zeile in meinem build.sbt sowohl in api als auch impl *
hinzugefügtlibraryDependencies + = Filter
In meinem impl-Verzeichnis habe ich Ordnerfilter erstellt und den Code unter
hinzugefügt %Vor%In meiner application.conf habe ich den folgenden Code hinzugefügt
%Vor%Danach habe ich meine Lagom Microservices neu gestartet und es hat wie ein Zauber funktioniert.
Tags und Links java angular cors playframework