2017-09-17 3 views
0

J'ai une application JAX-RS (RestEasy, 3.1.2.Final) exécutée sur une instance Apache Tomcat (8.5.2) intégrée. Ceci est un service public REST j'ai donc ajouté un filtre CORS de RestEasy lui:Apache Tomcat 8.5.2 + Resteasy Le filtre CORS cesse de fonctionner soudainement

import org.jboss.resteasy.plugins.interceptors.CorsFilter; 

@Override 
    public Set<Object> getSingletons() { 
     Set<Object> singletons = new LinkedHashSet<>(); 

     // = = = CORS = = = 
     CorsFilter cors = getCorsFilter(); 
     singletons.add(cors); 

     //... 

     return singletons; 
    } 

    private CorsFilter getCorsFilter() { 
     CorsFilter cors = new CorsFilter(); 
     cors.getAllowedOrigins().add("*"); 
     cors.setAllowCredentials(true); 
     cors.setAllowedMethods("GET,POST,PUT,DELETE,HEAD"); 
     cors.setCorsMaxAge(1209600); 
     cors.setAllowedHeaders("Origin,Accept,X-Requested-With,Content-Type,Access-Control-Request-Method,Access-Control-Request-Headers,Authorization,Accept-Encoding,Accept-Language,Access-Control-Request-Method,Cache-Control,Connection,Host,Referer,User-Agent"); 
     return cors; 
    } 

Il y a une contrainte de sécurité définie dans web.xml ainsi:

<security-constraint> 
     <web-resource-collection> 
      <web-resource-name>Tango RESTful gateway</web-resource-name> 
      <url-pattern>/rest/*</url-pattern> 
      <http-method>GET</http-method> 
      <http-method>HEAD</http-method> 
      <http-method>POST</http-method> 
      <http-method>PUT</http-method> 
      <http-method>DELETE</http-method> 
     </web-resource-collection> 
     <auth-constraint> 
      <role-name>desy-user</role-name> 
      <role-name>mtango-rest</role-name> 
     </auth-constraint> 
    </security-constraint> 

Dans ce tout installation fonctionne bien MAIS pour quelques semaines. Après quelques semaines CORS prévol échoue avec 401 au lieu de la séquence normale:

Demande:

Host: mstatus.esrf.fr 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 
Accept-Language: en-US,en;q=0.5 
Accept-Encoding: gzip, deflate, br 
Access-Control-Request-Method: GET 
Access-Control-Request-Headers: authorization 
Origin: https://ingvord.github.io 
DNT: 1 
Connection: keep-alive 

Réponse:

Connection: Keep-Alive 
Content-Length: 62 
Content-Type: application/octet-stream 
Date: Sun, 17 Sep 2017 07:28:19 GMT 
Keep-Alive: timeout=5, max=85 
Server: Apache-Coyote/1.1 

Cors Il est évident que le filtre n'est pas exécuté plus - il n'y a pas les en-têtes de réponse qu'il définit.

Quelle pourrait être la raison d'un tel comportement? Encore une fois cela fonctionne pendant quelques semaines après un redémarrage.

lien Application: https://ingvord.github.io/tango-controls.demo/

Merci à l'avance,

Répondre

0

Apparemment, il semble que la configuration supplémentaire suivante dans web.xml a résolu le problème:

<security-constraint> 
    <web-resource-collection> 
     <web-resource-name>CORS preflight</web-resource-name> 
     <url-pattern>/*</url-pattern> 
     <http-method>OPTIONS</http-method> 
    </web-resource-collection> 
</security-constraint> 

Eh bien, au moins nous ne observer toute mauvaise conduite pendant une assez longue période de temps.