September 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFWIP-342) Bootable JAR - RESTEasy JAXB end-point return unexpected 400 response

by Jean Francois Denise (Jira)

[ https://issues.redhat.com/browse/WFWIP-342?page=com.atlassian.jira.plugin... ] Jean Francois Denise commented on WFWIP-342: -------------------------------------------- I can only reproduce with Bootable JAR, problem is unrelated to galleon. It is caused by some JBoss module magic done to set the proper JAXP factories at boot. I logged WFCORE-5110 > Bootable JAR - RESTEasy JAXB end-point return unexpected 400 response > --------------------------------------------------------------------- > > Key: WFWIP-342 > URL: https://issues.redhat.com/browse/WFWIP-342 > Project: WildFly WIP > Issue Type: Bug > Reporter: Marek Kopecky > Assignee: Jean Francois Denise > Priority: Blocker > > RFE link: EAP7-1385 > RESTEasy JAXB end-point on bootable jar return unexpected 400 response with these security params: > {code:xml} > <context-param> > <param-name>resteasy.document.secure.processing.feature</param-name> > <param-value>true</param-value> > </context-param> > <context-param> > <param-name>resteasy.document.secure.disableDTDs</param-name> > <param-value>false</param-value> > </context-param> > <context-param> > <param-name>resteasy.document.expand.entity.references</param-name> > <param-value>false</param-value> > </context-param> > {code} > Used layers: > * jaxrs-server > * microprofile-config > Although this test is security related, AFAIK this is not related with legacy-security/elytron configuration, because related params are used in javax.xml.parsers.DocumentBuilderFactory directly from RESTEasy. Anyway let me know if I'm wrong. > Steps to reproduce: > # use installed WF version with reasonable layers, eg: WF_VERSION=21.0.0.Beta1-SNAPSHOT # > # git clone git@github.com:marekkopecky/Resteasy.git -b bootable-jar-3-12-secure-processing > # cd Resteasy > # mvn install -DskipTests -Dcheckstyle.skip=true > # cd testsuite > # mvn install:install-file -Dpackaging=pom -Dfile=pom.xml -DpomFile=pom.xml > # cd integration-tests > # mvn clean install -Dts.bootable -Ddefault=false -Ddisable.microprofile.tests -Dserver.version=${WF_VERSION} -Dserver.home=placeholder -Dcheckstyle.skip=true -Denforcer.skip -Dcheckstyle.skip=true -Dmaven.test.redirectTestOutputToFile=false > I can move these steps outside of TS, but I believe that TS doesn't affects this bootable jar behaviour, so it doesn't seem to be necessary. > I see just this unexpected&suspicious console output although I'm not sure whether it's related or not: > {noformat} > [org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 189; External DTD: Failed to read external DTD 'SecureProcessing_external.dtd', because 'file' access is not allowed due to restriction set by the accessExternalDTD property.] > {noformat} > cc: [~fburzigo], [~yersan], [~asoldano], [~ron_sigal] -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-5110) Bootable JAR doesn't setup the JAXP factories at boot

by Jean Francois Denise (Jira)

Jean Francois Denise created WFCORE-5110: -------------------------------------------- Summary: Bootable JAR doesn't setup the JAXP factories at boot Key: WFCORE-5110 URL: https://issues.redhat.com/browse/WFCORE-5110 Project: WildFly Core Issue Type: Bug Components: Bootable JAR Reporter: Jean Francois Denise Assignee: Jean Francois Denise We can observe invalid behavior such as WFWIP-342 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13559) Header response has changed and missing fields

by Emmanuel Hugonnet (Jira)

[ https://issues.redhat.com/browse/WFLY-13559?page=com.atlassian.jira.plugi... ] Emmanuel Hugonnet commented on WFLY-13559: ------------------------------------------ We are setting a second resteasy.providers context param instead of appending the filter to it so this might be the cause. > Header response has changed and missing fields > ---------------------------------------------- > > Key: WFLY-13559 > URL: https://issues.redhat.com/browse/WFLY-13559 > Project: WildFly > Issue Type: Bug > Affects Versions: 19.0.0.Final, 19.1.0.Final, 20.0.0.Final > Reporter: Alexandru Ciouca > Assignee: Bartosz Baranowski > Priority: Major > Attachments: standalone_18.0.0.final.xml, standalone_19.1.0.final.xml, test-endpoint-BEANS-XML.war, test-endpoint-CONTEXT.war, test-endpoint-WORKING.war > > > I have an application running in WildFly with some open endpoints to call and I tried an upgrade to WildFly 19.1.0.final from 18.0.0.final, but I noticed that something changed when calling the endpoints. In the Response Header I see that some of the fields are changed or are missing. Is this supposed to happen or do I need to add some extra configuration with WildFly 19? > Response WildFly 18.0.0.final: > {code} > HTTP/2 500 > cache-control: no-store, no-cache, must-revalidate > set-cookie: JSESSIONID=pLpPEvZZVekh0Bkqq06muz_cJ4_fmwxsqrt0HUdP.myservices-container-6f5b87f79d-ngzhf; path=/myservices > access-control-allow-headers: origin, content-type, accept, X-XSRF-TOKEN > content-type: application/json > content-length: 182 > link: <http://test.com/afs/rest>; rel="profile" > date: Thu, 04 Jun 2020 07:34:10 GMT > set-cookie: 7951a12696148c7a83e36db56eeb5f91=5ede0885e2c831c4946125e91d3facba; path=/; HttpOnly; Secure > strict-transport-security: max-age=31536000; includeSubdomains > x-xss-protection: 1; mode=block > x-content-type-options: nosniff > x-frame-options: SAMEORIGIN > {code} > Response WildFly 19.1.0.final: > {code} > HTTP/2 200 > set-cookie: JSESSIONID=9siDVU14OoFXojIIVxlMWbxNg1gcuSmLokwamY29.myservices-container-7c8dbf55f5-ctcks; path=/myservices > content-type: application/json > content-length: 182 > date: Thu, 04 Jun 2020 07:27:57 GMT > set-cookie: 7951a12696148c7a83e36db56eeb5f91=3edfc7a7549d107b41669532f6cb594a; path=/; HttpOnly; Secure > cache-control: private > strict-transport-security: max-age=31536000; includeSubdomains > x-xss-protection: 1; mode=block > x-content-type-options: nosniff > x-frame-options: SAMEORIGIN > {code} > As you can see the first thing that changed is the response code, even though the code is the same for both versions. The cache-control is also different and access-control-allow-headers and link fields are missing. > I am attaching also the standalone.xml for both versions. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-5614) Executable model generates a non-compiling beta index when in an equal constraint the left type is not assignable from the right one

by Mario Fusco (Jira)

Mario Fusco created DROOLS-5614: ----------------------------------- Summary: Executable model generates a non-compiling beta index when in an equal constraint the left type is not assignable from the right one Key: DROOLS-5614 URL: https://issues.redhat.com/browse/DROOLS-5614 Project: Drools Issue Type: Bug Components: executable model Reporter: Mario Fusco Assignee: Mario Fusco -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-5109) Ensure the log manager configurator is attached to the root logger

by James Perkins (Jira)

James Perkins created WFCORE-5109: ------------------------------------- Summary: Ensure the log manager configurator is attached to the root logger Key: WFCORE-5109 URL: https://issues.redhat.com/browse/WFCORE-5109 Project: WildFly Core Issue Type: Bug Components: Bootable JAR, Logging Reporter: James Perkins Assignee: James Perkins The entry point for the bootable JAR configures a custom log context. The logging subsystem looks on the root logger of that context to locate the {{Configurator}} which was used to configure the context. The configurator should be attached to the root logger so the subsystem locate it. Without this the context will be reconfigured resulting in possible truncation of log messages. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (WFWIP-339) OpenSSL security provider seems to be used when not defined with JDK8 now

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/WFWIP-339?page=com.atlassian.jira.plugin... ] Farah Juma commented on WFWIP-339: ---------------------------------- [~jstourac] Yes, I was using JDK 1.8.0_261. I'll try 1.8.0_241 today. Thanks! > OpenSSL security provider seems to be used when not defined with JDK8 now > ------------------------------------------------------------------------- > > Key: WFWIP-339 > URL: https://issues.redhat.com/browse/WFWIP-339 > Project: WildFly WIP > Issue Type: Bug > Components: Security > Reporter: Jan Stourac > Assignee: Farah Juma > Priority: Major > Attachments: client.jks, server.jks, standalone-full.xml > > > It looks like the OpenSSL security provider is now used as a default when I configure reverse-proxy feature on the server. Not sure what is the root-cause for this change of behavior. I also see this change of behavior only with JDK8. JDK11 works as expected! > Attaching relevant configuration. There can be also seen that during the startup, relevant log message about OpenSSL provider is logged during the server boot, e.g.: > {quote} > 16:44:42,676 INFO [org.wildfly.openssl.SSL] (MSC service thread 1-3) WFOPENSSL0002 OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016 > {quote} > This INFO message starts to occur in the server log since 'server-ssl-context' or 'client-ssl-contexts' are added into the server configuration and server is started with JDK8: > {code} > <server-ssl-contexts> > <server-ssl-context name="server-ssl-context" need-client-auth="true" key-manager="server-ssl-contextKM" trust-manager="server-ssl-contextTM"/> > </server-ssl-contexts> > <client-ssl-contexts> > <client-ssl-context name="proxy-ssl-context" key-manager="proxy-ssl-contextKM" trust-manager="proxy-ssl-contextTM"/> > </client-ssl-contexts> > {code} > There are two questions from this: > # Is this change of OpenSSL provider being initialized during the boot in this configuration case expected? > # I believe that even in case that answer to question above is `yes`, then we should not change default security provider, which in this case it should be JSSE. Not to mention that we don't want to behave differently for JDK8 and JDK11. > Hope I don't have any misconfiguration in the configuration itself. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-5613) Disable Trusty pmml when jpmml is present

by Gabriele Cardosi (Jira)

Gabriele Cardosi created DROOLS-5613: ---------------------------------------- Summary: Disable Trusty pmml when jpmml is present Key: DROOLS-5613 URL: https://issues.redhat.com/browse/DROOLS-5613 Project: Drools Issue Type: Task Reporter: Gabriele Cardosi Assignee: Gabriele Cardosi Inside trusty PMMLAssembler: 1. copy/refactor isjPMMLAvailableToClassLoader (from legacy PMMLAssembler) 2. modify {code:java} private static boolean isToEnable() {code} to always return "false" when jpmml is present Inside legacy PMMLAssembler: 1. modify {code:java} private static boolean isToEnable() {code} to always return "false" when jpmml is present 2. remove isjPMMLAvailableToClassLoader invocation from {code:java} private void addPackage(Resource resource) {code} 3. modify isjPMMLAvailableToClassLoader to log when jpmml is present -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-5103) Adding non existent and not required keystore fails

by Martin Mazánek (Jira)

[ https://issues.redhat.com/browse/WFCORE-5103?page=com.atlassian.jira.plug... ] Martin Mazánek reassigned WFCORE-5103: -------------------------------------- Assignee: Martin Mazánek (was: Darran Lofthouse) > Adding non existent and not required keystore fails > --------------------------------------------------- > > Key: WFCORE-5103 > URL: https://issues.redhat.com/browse/WFCORE-5103 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Jean Francois Denise > Assignee: Martin Mazánek > Priority: Major > Fix For: 13.0.0.Beta6 > > > We are in a case where a CLI script is executed in an embedded server. They keystore added doesn't exist locally when the script is run. The operation is: > /subsystem=elytron/key-store=keystore:add(required=false, path="/etc/foo/keystore.jks", credential-reference=\{clear-text=${keystore.password}}) > Error: > "failure-description" => {"WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.keystore" => "WFLYELY00004: Unable to start the service. > [ERROR] Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYELY00022: KeyStore file '/etc/wf-secrets/keystore.jks' does not exist and required."}}, -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-5103) Adding non existent and not required keystore fails

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/WFCORE-5103?page=com.atlassian.jira.plug... ] Farah Juma updated WFCORE-5103: ------------------------------- Priority: Major (was: Blocker) > Adding non existent and not required keystore fails > --------------------------------------------------- > > Key: WFCORE-5103 > URL: https://issues.redhat.com/browse/WFCORE-5103 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Jean Francois Denise > Assignee: Darran Lofthouse > Priority: Major > Fix For: 13.0.0.Beta6 > > > We are in a case where a CLI script is executed in an embedded server. They keystore added doesn't exist locally when the script is run. The operation is: > /subsystem=elytron/key-store=keystore:add(required=false, path="/etc/foo/keystore.jks", credential-reference=\{clear-text=${keystore.password}}) > Error: > "failure-description" => {"WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.keystore" => "WFLYELY00004: Unable to start the service. > [ERROR] Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYELY00022: KeyStore file '/etc/wf-secrets/keystore.jks' does not exist and required."}}, -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-5103) Adding non existent and not required keystore fails

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/WFCORE-5103?page=com.atlassian.jira.plug... ] Farah Juma commented on WFCORE-5103: ------------------------------------ [~mmazanek] Thanks for confirming! Did you want to assign this one to yourself to update the error message so it better describes the actual problem? > Adding non existent and not required keystore fails > --------------------------------------------------- > > Key: WFCORE-5103 > URL: https://issues.redhat.com/browse/WFCORE-5103 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Jean Francois Denise > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 13.0.0.Beta6 > > > We are in a case where a CLI script is executed in an embedded server. They keystore added doesn't exist locally when the script is run. The operation is: > /subsystem=elytron/key-store=keystore:add(required=false, path="/etc/foo/keystore.jks", credential-reference=\{clear-text=${keystore.password}}) > Error: > "failure-description" => {"WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.keystore" => "WFLYELY00004: Unable to start the service. > [ERROR] Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYELY00022: KeyStore file '/etc/wf-secrets/keystore.jks' does not exist and required."}}, -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2020