2012-06-08 15 views
6

Czy można skonfigurować wysyłanie niestandardowego nagłówka odpowiedzi HTTP z pliku solrconfig.xml? Myślę, że może być możliwe dodanie konfiguracji do sekcji <requestDispatcher>, ponieważ kontroluje ona nagłówki buforowania.Apache Solr: Ustawianie nagłówków odpowiedzi HTTP z solrconfig.xml Dla CORS

Jestem pewien, że jest to możliwe w konfiguracji kontenera serwletów (Jetty, Tomcat itp.), Ale chciałbym to zrobić z plików konfiguracyjnych Solra, jeśli to w ogóle możliwe.

Jeśli to robi jakąkolwiek różnicę, próbuję ustawić nagłówek Access-Control-Allow-Origin dla żądań CORS AJAX z innego hosta.

Odpowiedz

7

Zamiast tego można użyć JSONP. Zobacz ten link na przykład

+0

Dzięki za link. Zdecydowanie uwzględnię to w moim przypadku, ale chciałbym, aby w miarę możliwości działał prawdziwy CORS. –

+0

Przepraszam, że zajęło Ci to tyle czasu, by dać ci kredyt. W końcu zaimplementowałem to rozwiązanie i zakończyłem pracę z JSONP, ponieważ wsparcie dla niego jest wbudowane w Solr. –

1

Najprościej będzie napisać niestandardowy javax.servlet.Filter i dodać tam nagłówek Access-Control-Allow-Origin. Dla kodu obsługującego przetwarzanie HTTP zobacz klasę org.apache.solr.servlet.SolrDispatchFilter.

Jest to najłatwiejszy sposób postępowania. Jeśli spojrzysz na filtr doFillter w SolrDispatchFilter - jedyną manipulacją przy użyciu nagłówków HTTP jest ich buforowanie i nie ma miejsca, które by ich dotykało w jakiś sposób.

0

front solr z apache i conf apache do odesłania nagłówka. Na przykład:

Header set X-Server-Name "abc0.com" 
0

Znalazłem this pomocne. Aby włączyć CORS, musisz dodać kilka słoików pomostowych i zmianę webdefault.xml.

Jestem odtwarzając tekst tutaj:


W projekcie przykład solr po uruchomieniu go przez wywołanie następujący wiersz:

java -jar rozpocząć

Jesteś Rozpoczynanie Serwer Jetty na lokalnym komputerze, który będzie obsługiwał wyniki solr. Ten serwer nie jest w stanie wykonać CORS (Cross Origin Resource Sharing). Oznacza to, że jeśli próbowałbyś wykonać wywołanie AJAX ze strony o innym pochodzeniu niż sam serwer, odmówiono by ci odpowiedzi.

Aby to naprawić, najpierw trzeba uzyskać odpowiednie słoiki, aby umożliwić współdzielenie zasobów między domenami.

użyłem następujące słoika: http://repo1.maven.org/maven2/org/eclipse/jetty/jetty-servlets/8.1.10.v20130312/

Ale może trzeba pobrać wersję, który jest odpowiedni dla danej wersji pomost: http://repo1.maven.org/maven2/org/eclipse/jetty/jetty-servlets/

można dowiedzieć się, jaka wersja Jetty używasz z przykładu solr przechodząc: java -jar rozpocznie --version

a zobaczysz zrzut następująco: C: \ Users \ nazwa_użytkownika \ Pulpit \ SOLR-4.8.0 \ example> java -jar start.jar --version Aktywne opcje: [domyślnie, *] Informacje o wersji 18 pozycji w ścieżce klas. Uwaga: kolejność tutaj przedstawiona przedstawia sposób ich wyświetlania w ścieżce klas. Zmiany opcji OPCJE = [opcja, opcja, ...] zostaną odzwierciedlone jako ponownie.

0:    (dir) | ${jetty.home}\resources 
1:  8.1.10.v20130312 | ${jetty.home}\lib\jetty-xml-8.1.10.v20130312.jar 
2: 3.0.0.v201112011016 | ${jetty.home}\lib\servlet-api-3.0.jar 
3:  8.1.10.v20130312 | ${jetty.home}\lib\jetty-http-8.1.10.v20130312.jar 
4:  8.1.10.v20130312 | ${jetty.home}\lib\jetty-continuation-8.1.10.v20130312.jar 
5:  8.1.10.v20130312 | ${jetty.home}\lib\jetty-server-8.1.10.v20130312.jar 
6:  8.1.10.v20130312 | ${jetty.home}\lib\jetty-security-8.1.10.v20130312.jar 
7:  8.1.10.v20130312 | ${jetty.home}\lib\jetty-servlet-8.1.10.v20130312.jar 
8:  8.1.10.v20130312 | ${jetty.home}\lib\jetty-webapp-8.1.10.v20130312.jar 
9:  8.1.10.v20130312 | ${jetty.home}\lib\jetty-deploy-8.1.10.v20130312.jar 
10:  8.1.10.v20130312 | ${jetty.home}\lib\jetty-servlets-8.1.10.v20130312.jar 
11:    1.7.6 | ${jetty.home}\lib\ext\jcl-over-slf4j-1.7.6.jar 
12:    1.7.6 | ${jetty.home}\lib\ext\jul-to-slf4j-1.7.6.jar 
13:    1.2.16 | ${jetty.home}\lib\ext\log4j-1.2.16.jar 
14:    1.7.6 | ${jetty.home}\lib\ext\slf4j-api-1.7.6.jar 
15:    1.7.6 | ${jetty.home}\lib\ext\slf4j-log4j12-1.7.6.jar 
16:  8.1.10.v20130312 | ${jetty.home}\lib\jetty-util-8.1.10.v20130312.jar 
17:  8.1.10.v20130312 | ${jetty.home}\lib\jetty-io-8.1.10.v20130312.jar 

Spójrz na linii, która mówi $ {jetty.home} \ lib \ molo-serwer (w wysypisko powyżej to linia 5) i powinieneś być w stanie zobaczyć swoją wersję.

Będziesz także chcą uzyskać „pomost-util” dla danej wersji pomost TOO: http://mvnrepository.com/artifact/org.mortbay.jetty/jetty-util

Powinieneś być w stanie znaleźć tam swoją wersję. Użyłem jetty-util-8.1.10.v20130312.jar dla mojego.

Teraz podjąć zarówno servlet.jar i util.jar pliki, które możesz pobrać i umieścić go w następującym folderze: solr-4.8.0 \ example \ lib

dla danej wersji może być różne, ale ci chcesz go w folderze lib w katalogu example.

Wreszcie, aby umożliwić te zmiany zaczęły wpływać, chcesz otworzyć SOLR-4.8.0 \ example \ etc \ webdefault.xml

i dodaj następujące wiersze przed </web-app>:

<filter> 
     <filter-name>cross-origin</filter-name> 
     <filter-class>org.eclipse.jetty.servlets.CrossOriginFilter</filter-class> 
    </filter> 
    <filter-mapping> 
     <filter-name>cross-origin</filter-name> 
     <url-pattern>/*</url-pattern> 
    </filter-mapping> 

Teraz zrestartuj serwer i włącz CORS.

Notatki: Jeśli zaczniesz mieć ochotę i będziesz mieć wiele aplikacji internetowych działających na przykładowym serwerze pomostu solr, to wpłynie to na wszystkie te aplikacje internetowe. Należy pamiętać, że ustawiono parametr url, aby rozpoznawał każdą domenę niebezpieczną dla konfiguracji produkcyjnej. Dotyczy tylko testów lokalnych.

Próbowałem również zmienić plik web.xml w folderze webapps, aby zmiany te pozostały lokalne, ale po wielu godzinach próbowania uruchomienia, dałem za wygraną i odkryłem, że wstawienie go do globalnego webdefault zadziałało .

Powiązane problemy