web-dev-qa-db-fra.com

Client de service Web CXF: "Impossible de créer un XMLInputFactory sécurisé"

Je suis écrit et déployé un service Web CXF sur un serveur Tomcat en utilisant les instructions ici . Le service Web se déploie correctement car je peux voir le fichier WSDL dans un navigateur Web.

Mon programme client Java autonome ne fonctionne pas cependant. Voici le code:

System.out.println("Creating client");
Properties properties = System.getProperties();
properties.put("org.Apache.cxf.stax.allowInsecureParser", "1");
System.setProperties(properties);
JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
factory.setServiceClass(ExampleWebService.class);
factory.setAddress("http://X.X.X.X:9090/WebServices/ExampleWebService");
ExampleWebService exampleWebService = (ExampleWebService)factory.create();
System.out.println("Done creating client");
exampleWebService.method1("test");
System.out.println("After calling method1");

J'ai copié tous les fichiers jar (y compris le fichier woodstox-core-asl-4.2.0.jar) de la distribution CXF 2.7.7 dans le chemin de classe du programme client. Lorsque j'exécute le client, l'exception suivante est générée:

Creating client
Nov 20, 2013 8:05:26 PM org.Apache.cxf.service.factory.ReflectionServiceFactoryBean buildServiceFromClass
INFO: Creating Service {http://webservices.server/}ExampleWebServiceService from class server.webservices.ExampleWebService
Done creating client
javax.xml.ws.soap.SOAPFaultException: Cannot create a secure XMLInputFactory
    at org.Apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.Java:157)
    at $Proxy38.printString(Unknown Source)
    at ExampleNmsWebServiceClient.printString(ExampleNmsWebServiceClient.Java:29)
    at ExampleNmsWebServiceClient.main(ExampleNmsWebServiceClient.Java:40)
Caused by: org.Apache.cxf.binding.soap.SoapFault: Cannot create a secure XMLInputFactory
    at org.Apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.unmarshalFault(Soap11FaultInInterceptor.Java:84)
    at org.Apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.Java:51)
    at org.Apache.cxf.binding.soap.interceptor.Soap11FaultInInterceptor.handleMessage(Soap11FaultInInterceptor.Java:40)
    at org.Apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.Java:272)
    at org.Apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.Java:113)
    at org.Apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.Java:69)
    at org.Apache.cxf.binding.soap.interceptor.CheckFaultInterceptor.handleMessage(CheckFaultInterceptor.Java:34)
    at org.Apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.Java:272)
    at org.Apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.Java:835)
    at org.Apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.Java:1606)
    at org.Apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.Java:1502)
    at org.Apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.Java:1309)
    at org.Apache.cxf.transport.AbstractConduit.close(AbstractConduit.Java:56)
    at org.Apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.Java:627)
    at org.Apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.Java:62)
    at org.Apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.Java:272)
    at org.Apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.Java:565)
    at org.Apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.Java:474)
    at org.Apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.Java:377)
    at org.Apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.Java:330)
    at org.Apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.Java:96)
    at org.Apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.Java:135)
    ... 3 more

J'ai trouvé une page disant que "Impossible de créer une XMLInputFactory sécurisée" peut être corrigée en définissant la propriété org.Apache.cxf.stax.allowInsecureParser sur "1". ça marche pas. J'ai également essayé d'ajouter -Dorg.Apache.cxf.stax.allowInsecureParser = 1 à la commande Java qui exécute le client, mais cela ne fonctionnait pas non plus. (Pas plus que la définition de "true" au lieu de 1.) Des idées sur la façon de résoudre cette erreur?

web-servicescxfwoodstox
21
pacoverflow

Avait ce problème lors de la mise à niveau de CXF 2.3.x à 2.7.x

Ajouté stax2-api et woodstox-core-asl jars de la distribution 2.7.x CXF et le service Web fonctionne à nouveau.

23
Lund Wolfe

Depuis la version 2.7.4, CXF a ajouté une fonctionnalité permettant de s’assurer que XMLInputFactory est sécurisé et chargé depuis woodstox (paquets => 4.2.x, voir StaxUtil ) afin de traiter un Refus. de vulnérabilité de service

Mais le fait est que dans un environnement J2EE, par défaut, webservices-rt.jar a la priorité sur les bibliothèques de guerre (et ensuite sur le bocal woodstock). C'est pourquoi l'implémentation non sécurisée est chargée, déclenchant l'exception.

Si vous désactivez la propriété org.Apache.cxf.stax.allowInsecureParser, n’est pas une option car elle renvoie la vulnérabilité DOS.

Pour que le chargeur de classe préfère woodstox (ear/war lib) à webservices-rt.jar (j2ee lib), la solution dépend de votre serveur d'applications et est décrite dans Guide de configuration spécifique au serveur d'applications CXF

18
yunandtidus

J'ai eu le même problème 

Après avoir ajouté ce -Dorg.Apache.cxf.stax.allowInsecureParser=1 au Java_OPTIONS dans setDomainEnv.sh, cela fonctionne bien maintenant.

16
Krish

J'ai eu ce problème sur weblogic et je l'ai corrigé en l'ajoutant à mon weblogic-application.xml

<prefer-application-packages>
       <package-name>com.ctc.wstx.*</package-name>
</prefer-application-packages>
13
ghost_1989

Recherchez toutes les autres versions de Woodstox qui peuvent être trouvées sur le chemin de classe ou dans le répertoire lib/ended de jre ou similaire. Cela ressemble à une ancienne version 4.1 peut être ramassé.

9
Daniel Kulp

J'ai eu le même problème lorsque j'ai mis à niveau CXF vers la version 2.7.x. J'ai résolu ce problème en ajoutant les dépendances suivantes dans POM

<dependency>
    <groupId>org.codehaus.woodstox</groupId>
    <artifactId>stax2-api</artifactId>
    <version>4.0.0</version>
</dependency>
<dependency>
    <groupId>org.codehaus.woodstox</groupId>
    <artifactId>woodstox-core-asl</artifactId>
    <version>4.4.1</version>
</dependency>
4
Vaibhav

Il n'y a pas eu de réponse ici qui décrit la cause première de ce message d'erreur pour mon problème. Nous avions des dépendances transitives à la fois sur une nouvelle version Woodstox-core-asl-4.2.0.jar Et sur un ancien Wstx-asl-3.2.1.jar

Exclure l'ancienne version de notre version a fait l'affaire.

Si vous creusez dans les entrailles de l'ancienne version, vous constaterez que celle-ci échoue avec une exception qui finit par être encapsulée dans une autre exception avec ce message générique peu informatif.

4
Tom Hartwell

J'ai trouvé ce problème et c'est parce que, lorsque j'ai mis à niveau une ancienne version de cxf, je n'ai pas modifié stax-api - *. Jar en stax2-api - *. Jar dans mon classpath client.

2
Peter Jamieson

Si vous passez à la version 3.0.0 ou ultérieure, vous ne devriez pas ajouter woodstock

2
Jad B.

Dans mon cas, il y avait deux pots (Cxf 3.0.1, Jboss 7.1.1)

javax.xml.stream:stax-api:jar:1.0-2:compile

org.codehaus.woodstox: stax2-api: jar: 3.1.4: compiler

J'ai enlevé le 1er et ça a commencé à fonctionner

0
Praveen

de mon côté, je devais faire les deux supprimer le fichier stax-api-1.0-2.jar (en laissant stax2-api-3.1.4.jar & woodstock 4.4 jar) et spécifier dans le fichier weblogic-application.xml : 

     .
     .
     <package-name>com.ctc.wstx.*</package-name>  
     <package-name>org.codehaus.stax2.*</package-name>
 </prefer-application-packages>
0
Carlos Guizar

Le problème venait de fichiers jar CXF manquants dans le déploiement du service Web sur le serveur. C'était difficile à déboguer car il n'y avait pas d'erreur sur le serveur.

0
pacoverflow

J'ai parcouru mes dépendances pour trouver des conflits de version avec woodstox ou stax-api.

Il s'avère que axis2-transport-http a introduit ces conflits. 

Si vous avez également cette dépendance, ajoutez l’exclusion suivante à votre dépendance de pom qui l’a introduite.

<exclusions>
            <exclusion>
                <groupId>org.Apache.axis2</groupId>
                <artifactId>axis2-transport-http</artifactId>
            </exclusion>
        </exclusions>
0
Yoozzii

Je peux résoudre ce problème en ajoutant weblogic.xml dans le dossier WEB-INF de mon application avec le code suivant:

<prefer-web-inf-classes>false</prefer-web-inf-classes>

<prefer-application-packages>
    <package-name>com.ctc.*</package-name>
</prefer-application-packages>

0
Aldo Fernando Saia

J'ai eu ce problème sur weblogic, l'application a été déployée avec succès, mais lorsque j'ai lancé la requête soap, j'ai obtenu l'erreur suivante: impossible de créer un XMLInputFactory sécurisé.

résolu le problème en ajoutant ce paquet à weblogic-application.xml

com.ctc.wstx. *

0
Megha