CORS preflight-request scheitert an einer standard-header

Beim Debuggen eines CORS Frage, die ich erlebe, die ich gefunden habe das folgende Verhalten. Chrom macht den folgenden OPTIONEN preflight-request (umgeschrieben in CURL von Chrome selbst):

curl -v 'https://www.example.com/api/v1/users' -X OPTIONS -H 'Access-Control-Request-Method: POST' -H 'Origin: http://example.com' -H 'Accept-Encoding: gzip,deflate,sdch' -H 'Accept-Language: es-ES,es;q=0.8,en;q=0.6' -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36' -H 'Accept: */*' -H 'Referer: http://example.com/users/new' -H 'Connection: keep-alive' -H 'Access-Control-Request-Headers: accept, x-api-key, content-type'

Die Antwort des Servers auf diese Anfrage, wenn die folgenden:

< HTTP/1.1 403 Forbidden
< Date: Thu, 21 Jul 2016 14:16:56 GMT
* Server Apache/2.4.7 (Ubuntu) is not blacklisted
< Server: Apache/2.4.7 (Ubuntu)
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
< Expires: 0
< Strict-Transport-Security: max-age=31536000 ; includeSubDomains
< X-Frame-Options: SAMEORIGIN
< Allow: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS, PATCH
< Content-Length: 20
< Keep-Alive: timeout=5, max=100
< Connection: Keep-Alive

den Körper von der Reaktion "Invalid CORS-request'. Wenn ich die Anfrage wiederholen das entfernen der header "Access-Control-Request-Methode' (und nur der header) OPTIONEN Anforderungen gelingt mit der folgenden Antwort:

< HTTP/1.1 200 OK
< Date: Thu, 21 Jul 2016 14:21:27 GMT
* Server Apache/2.4.7 (Ubuntu) is not blacklisted
< Server: Apache/2.4.7 (Ubuntu)
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
< Expires: 0
< Strict-Transport-Security: max-age=31536000 ; includeSubDomains
< X-Frame-Options: SAMEORIGIN 
< Access-Control-Allow-Headers: origin, content-type, accept, x-requested-with, x-api-key
< Access-Control-Max-Age: 60
< Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
< Access-Control-Allow-Origin: *
< Allow: GET, HEAD, POST, PUT, DELETE, TRACE, OPTIONS, PATCH
< Content-Length: 0
< Keep-Alive: timeout=5, max=100
< Connection: Keep-Alive

Jedoch die problematische header ist ein CORS-Spezifikation standard-header so sollte es nicht verhindern, dass die Anfrage erfolgreich, richtig? Warum ist dieser header verursacht ein solches Verhalten?

Und wie kann ich Sie optimieren die access-control-Header gesendet von meinem server, um eine Anfrage zu Arbeit und wenn mit Chrome?

Übrigens, ich bin mit Chrome 36.0, und der server ist mit Spring Boot, mit dem CORS-Header wird verwaltet von Spring.

Wenn der Antrag von Firefox (v47.0) ist das Verhalten anders, aber mit einem analogen Ergebnis. Firefox macht das auch nicht senden Sie die preflight-Anfrage, es direkt sendet den POST-request, der erhält als Antwort ein 403 Forbidden. Jedoch, wenn ich die Kopie der Anfrage mit der 'Copy als cURL" - option, und wiederholen Sie es in einem terminal-Fenster, gelingt Es, und sendet die richtige CORS-Header in der Antwort.

Irgendeine Idee?

Update: Firefox sendet den preflight-OPTIONS-Anfrage (dargestellt durch die Live HTTP Header plugin), aber Firebug Masken, so dass das Verhalten in beiden Browsern ist es genau dasselbe. In beiden Browsern ist die "Access-control-request-Methode' - header dem Unterschied, dass die Anfrage fehlschlagen.

InformationsquelleAutor joanlofe | 2016-07-21

cors spring

26

Nach viel kämpfen, habe ich endlich das problem gefunden. Ich konfigurierte eine Anfrage mapping im Frühjahr zu verarbeiten OPTIONEN traffic, wie diese:
```
@RequestMapping(value= "/api/**", method=RequestMethod.OPTIONS)
public void corsHeaders(HttpServletResponse response) {
    response.addHeader("Access-Control-Allow-Origin", "*");
    response.addHeader("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS");
    response.addHeader("Access-Control-Allow-Headers", "origin, content-type, accept, x-requested-with");
    response.addHeader("Access-Control-Max-Age", "3600");
}
```
Wusste ich nicht, dass durch Standard-Spring verwendet eine Standard-CORS Prozessor, und es scheint, es war, sich mit meiner Anfrage Zuordnung. Löscht meine Anfrage mapping und das hinzufügen der @CrossOrigin Kommentar zu der entsprechenden Anfrage Zuordnungen das problem gelöst.
- Ja, was für ein Kopf-trip, der Frühling ist ein Standard-cors Prozessor, aber es sei denn, Ihr konfiguriert, Sie tatsächlich unterbricht die normale CORS-Verarbeitung wenn Sie die Einstellungen in Apache. Sieht aus wie entweder konfigurieren Sie eine CorsFilter, oder befolgen Sie die Ratschläge hier - Frühling.io/guides/gs/rest-service-cors
- Ich fand diesen Beitrag auch hilfreich: stackoverflow.com/questions/9521690/... DispatchServlet konfiguriert werden müssen, um pass entlang options-Anfrage, oder aber es erreicht nie die zugeordnete Anforderung: ... <servlet> <servlet-name>yourServlet</servlet-name> <servlet-class>org.springframework.web.- servlet.DispatcherServlet</servlet-class> <init-param> <param-name>dispatchOptionsRequest</param-name> <param-value>true</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet - > ...
InformationsquelleAutor joanlofe

ich auch vor dem gleichen Problem und finden die Lösung für das aktivieren der globalen cors-Problem in spring boot

@Configuration
@EnableWebMvc
public class WebConfig extends WebMvcConfigurerAdapter {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**").allowedMethods("GET", "POST", "PUT", "DELETE").allowedOrigins("*")
                .allowedHeaders("*");
    }
}

nachdem diese , die wir brauchen, damit CORS im Frühjahr Sicherheitsstufe auch, also für diese
hinzufügen cors() in Ihrem SecurityConfiguration Klasse, in welchem Ausmaß WebSecurityConfigurerAdapter

 @Override
    protected void configure(HttpSecurity httpSecurity) throws Exception {

        httpSecurity
                .cors()
                .and()
                .csrf().disable()
                .authorizeRequests()..

    }

InformationsquelleAutor Om Sharma

Ich hatte das gleiche Problem. Habe ich lösen es, indem Sie 'OPTIONEN', um erlaubt CORS Methoden in meinem Spring MVC Konfiguration.

@Configuration
@EnableWebMvc
@ComponentScan
public class RestApiServletConfig extends WebMvcConfigurerAdapter {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        super.addCorsMappings(registry);
        registry.addMapping("/**")
                .allowedOrigins("http://localhost:3000", "http://localhost:8080")
                .allowedMethods("GET", "PUT", "POST", "DELETE", "OPTIONS");
    }
}

InformationsquelleAutor Alex Elkin

2

Bearbeiten: Aktivieren CORS in der security-Konfiguration und stellen Sie sicher Optionen Anforderungen umgehen Sicherheit
```
@Override
protected void configure(HttpSecurity httpSecurity) throws Exception {
    httpSecurity
            .cors()
            .and()
            .authorizeRequests()
            .antMatchers(HttpMethod.OPTIONS, "/**").permitAll()
            //More security configuration here
}
```
- Hinweis - Frühling in der Dokumentation ausdrücklich festgelegt: "Seit CORS-requests werden automatisch ausgelöst, Sie müssen nicht zum ändern der DispatcherServlet dispatchOptionsRequest init-parameter mit dem Wert; mit den voreingestellten Standardwert (false) ist die empfohlene Methode ist."
- du hast Recht, ändern dispatchOptionsRequest ist nicht notwendig
InformationsquelleAutor Stijn Van Bael

Fügte ich dies als eine Antwort, denn ich konnte Sie nicht formatieren, es auch für die top-Antwort gestimmt.

Ich fand diesen Beitrag hilfreich auch: Wie bei der Behandlung von HTTP-OPTIONEN mit Spring MVC?

DispatchServlet konfiguriert werden müssen, um pass entlang options-Anfrage, oder aber es erreicht nie die zugeordnete Anforderung:

...
  <servlet>
    <servlet-name>yourServlet</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
      <param-name>dispatchOptionsRequest</param-name>
      <param-value>true</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
  </servlet>
...

InformationsquelleAutor Mike

Für mich, die ich Hinzugefügt haben @crossorigin annotation in jeder controller-api-Aufruf.

@CrossOrigin
@PostMapping(path = "/getListOfIndividuals", produces = { "application/json" }, consumes = { "application/json" })
public ResponseEntity<String> test(@RequestBody String viewIndividualModel)
        throws Exception {
    String individualDetails = globalService.getIndividualDetails(viewIndividualModel);


    finalString = discSpecAssmentService.getViewFormForDisciplineEvaluation( viewIndividualModel);

    return new ResponseEntity<String>(finalString, HttpStatus.OK);
}

InformationsquelleAutor Prabu M

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.