July 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6875) Add ssl-enabled-protocol configuration parameter to IIOP subsystem

by Tomasz Adamski (JIRA)

[ https://issues.jboss.org/browse/WFLY-6875?page=com.atlassian.jira.plugin.... ] Tomasz Adamski commented on WFLY-6875: -------------------------------------- Add ability to specify allowed version of TLS/SSL protocol used by secured socket to iiop-openjdk subsystem. We need such configuration to be able to make sure that there is a possibility to turn off specific versions of protocol used (f.e. SSLv3 protocol to avoid POODLE attack). In most virtual machines (oracle and openjdk included) this change has been done already inside JVM configuration. Nevertheless adding such parameter to the subsystem will make it possible to configure this parameter no matter which JVM is used. > Add ssl-enabled-protocol configuration parameter to IIOP subsystem > ------------------------------------------------------------------ > > Key: WFLY-6875 > URL: https://issues.jboss.org/browse/WFLY-6875 > Project: WildFly > Issue Type: Enhancement > Components: IIOP > Affects Versions: 10.0.0.Final > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6875) Add ssl-enabled-protocol configuration parameter to IIOP subsystem

by Tomasz Adamski (JIRA)

[ https://issues.jboss.org/browse/WFLY-6875?page=com.atlassian.jira.plugin.... ] Tomasz Adamski updated WFLY-6875: --------------------------------- Description: Add ability to specify allowed version of TLS/SSL protocol used by secured socket to iiop-openjdk subsystem. We need such configuration to be able to make sure that there is a possibility to turn off specific versions of protocol used (f.e. SSLv3 protocol to avoid POODLE attack). In most virtual machines (oracle and openjdk included) this change has been done already inside JVM configuration. Nevertheless adding such parameter to the subsystem will make it possible to configure this parameter no matter which JVM is used. > Add ssl-enabled-protocol configuration parameter to IIOP subsystem > ------------------------------------------------------------------ > > Key: WFLY-6875 > URL: https://issues.jboss.org/browse/WFLY-6875 > Project: WildFly > Issue Type: Enhancement > Components: IIOP > Affects Versions: 10.0.0.Final > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > > Add ability to specify allowed version of TLS/SSL protocol used by secured socket to iiop-openjdk subsystem. We need such configuration to be able to make sure that there is a possibility to turn off specific versions of protocol used (f.e. SSLv3 protocol to avoid POODLE attack). In most virtual machines (oracle and openjdk included) this change has been done already inside JVM configuration. Nevertheless adding such parameter to the subsystem will make it possible to configure this parameter no matter which JVM is used. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6875) Add ssl-enabled-protocol configuration parameter to IIOP subsystem

by Tomasz Adamski (JIRA)

[ https://issues.jboss.org/browse/WFLY-6875?page=com.atlassian.jira.plugin.... ] Tomasz Adamski updated WFLY-6875: --------------------------------- Comment: was deleted (was: Add ability to specify allowed version of TLS/SSL protocol used by secured socket to iiop-openjdk subsystem. We need such configuration to be able to make sure that there is a possibility to turn off specific versions of protocol used (f.e. SSLv3 protocol to avoid POODLE attack). In most virtual machines (oracle and openjdk included) this change has been done already inside JVM configuration. Nevertheless adding such parameter to the subsystem will make it possible to configure this parameter no matter which JVM is used.) > Add ssl-enabled-protocol configuration parameter to IIOP subsystem > ------------------------------------------------------------------ > > Key: WFLY-6875 > URL: https://issues.jboss.org/browse/WFLY-6875 > Project: WildFly > Issue Type: Enhancement > Components: IIOP > Affects Versions: 10.0.0.Final > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > > Add ability to specify allowed version of TLS/SSL protocol used by secured socket to iiop-openjdk subsystem. We need such configuration to be able to make sure that there is a possibility to turn off specific versions of protocol used (f.e. SSLv3 protocol to avoid POODLE attack). In most virtual machines (oracle and openjdk included) this change has been done already inside JVM configuration. Nevertheless adding such parameter to the subsystem will make it possible to configure this parameter no matter which JVM is used. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6875) Add ssl-enabled-protocol configuration parameter to IIOP subsystem

by Tomasz Adamski (JIRA)

Tomasz Adamski created WFLY-6875: ------------------------------------ Summary: Add ssl-enabled-protocol configuration parameter to IIOP subsystem Key: WFLY-6875 URL: https://issues.jboss.org/browse/WFLY-6875 Project: WildFly Issue Type: Enhancement Components: IIOP Affects Versions: 10.0.0.Final Reporter: Tomasz Adamski Assignee: Tomasz Adamski -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1667) After a full-replace-deployment operation on a managed domain in a composite operation onf of the enabled timestamp is not updated

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1667?page=com.atlassian.jira.plugi... ] James Perkins commented on WFCORE-1667: --------------------------------------- Also note the test may require a short sleep before the reads of the hash to ensure the deployment is complete. I've had it fail twice now with unmatched byte arrays. > After a full-replace-deployment operation on a managed domain in a composite operation onf of the enabled timestamp is not updated > ---------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1667 > URL: https://issues.jboss.org/browse/WFCORE-1667 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: James Perkins > Assignee: Brian Stansberry > > When executing a {{full-replace-deployment}} in a composite operation the deployment associated with the first step does not get it's {{enabled-time}} attribute updated. The second one always has an updated attribute. > I've created a test to show the odd behavior, https://github.com/wildfly/wildfly-core/commit/452e2149571c87ff4cfcdfbd78.... Note that if you change the order of the archive arguments on the redeploy you'll see the failure happens on the second deployment instead of the first. > Do note that this test may not be needed, but it was an easy way to show what the issue is. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1667) After a full-replace-deployment operation on a managed domain in a composite operation onf of the enabled timestamp is not updated

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1667?page=com.atlassian.jira.plugi... ] James Perkins updated WFCORE-1667: ---------------------------------- Description: When executing a {{full-replace-deployment}} in a composite operation the deployment associated with the first step does not get it's {{enabled-time}} attribute updated. The second one always has an updated attribute. I've created a test to show the odd behavior, https://github.com/wildfly/wildfly-core/commit/452e2149571c87ff4cfcdfbd78.... Note that if you change the order of the archive arguments on the redeploy you'll see the failure happens on the second deployment instead of the first. Do note that this test may not be needed, but it was an easy way to show what the issue is. was:When executing a {{full-replace-deployment}} in a composite operation the deployment associated with the first step does not get it's {{enabled-time}} attribute updated. The second one always has an updated attribute. Steps to Reproduce: See test commit https://github.com/wildfly/wildfly-core/commit/452e2149571c87ff4cfcdfbd78... Summary: After a full-replace-deployment operation on a managed domain in a composite operation onf of the enabled timestamp is not updated (was: After a full-replace-deployment operation on a managed domain in a composite operation the first enabled timestamp is not updated) > After a full-replace-deployment operation on a managed domain in a composite operation onf of the enabled timestamp is not updated > ---------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1667 > URL: https://issues.jboss.org/browse/WFCORE-1667 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: James Perkins > Assignee: Brian Stansberry > > When executing a {{full-replace-deployment}} in a composite operation the deployment associated with the first step does not get it's {{enabled-time}} attribute updated. The second one always has an updated attribute. > I've created a test to show the odd behavior, https://github.com/wildfly/wildfly-core/commit/452e2149571c87ff4cfcdfbd78.... Note that if you change the order of the archive arguments on the redeploy you'll see the failure happens on the second deployment instead of the first. > Do note that this test may not be needed, but it was an easy way to show what the issue is. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1667) After a full-replace-deployment operation on a managed domain in a composite operation the first enabled timestamp is not updated

by James Perkins (JIRA)

James Perkins created WFCORE-1667: ------------------------------------- Summary: After a full-replace-deployment operation on a managed domain in a composite operation the first enabled timestamp is not updated Key: WFCORE-1667 URL: https://issues.jboss.org/browse/WFCORE-1667 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: James Perkins Assignee: Brian Stansberry When executing a {{full-replace-deployment}} in a composite operation the deployment associated with the first step does not get it's {{enabled-time}} attribute updated. The second one always has an updated attribute. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6874) Upgrade jsf-impl to 2.2.13.SP2

by Farah Juma (JIRA)

Farah Juma created WFLY-6874: -------------------------------- Summary: Upgrade jsf-impl to 2.2.13.SP2 Key: WFLY-6874 URL: https://issues.jboss.org/browse/WFLY-6874 Project: WildFly Issue Type: Component Upgrade Components: JSF Reporter: Farah Juma Assignee: Farah Juma This upgrade includes the fix for [JAVASERVERFACES-4130|https://java.net/jira/browse/JAVASERVERFACES-4130]. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6671) ajp connection hangs if a post HTTP request header contains 'Transfer-Encoding: chunked'

by river shen (JIRA)

[ https://issues.jboss.org/browse/WFLY-6671?page=com.atlassian.jira.plugin.... ] river shen closed WFLY-6671. ---------------------------- the work around is good enough. > ajp connection hangs if a post HTTP request header contains 'Transfer-Encoding: chunked' > ----------------------------------------------------------------------------------------- > > Key: WFLY-6671 > URL: https://issues.jboss.org/browse/WFLY-6671 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Final > Environment: Apache HTTP server 2.2.22 with mod_jk 1.2.37 > Reporter: river shen > Assignee: Stuart Douglas > Attachments: service-1.0-SNAPSHOT.war, src.zip, stacks.txt, standalone.xml, workers.properties > > > When upgrading from JBOSS 7 to WILDFLY10, we observed following behavior: > if an HTTP post contains 'Transfer-Encoding: chunked' and 'Content-Type:appliation/octet-stream' in its head, A servlet which handles it will hang for ever ( until the client drop the connection) if it calls HttpServletRequest.getInputStream() and tries to read the whole content of the returned InputStream. The InputStream's read() method will block for ever at the end of the stream as opposed to return -1. > It only happens when the request is routed by apache web server through ajp; it does not happen if the client talks to wildfly directly through its 8080 http port. > We have attached a minimal web application that reproduce this issue. > Also attached is the standalone.xml and the apache configuration file. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6767) security-realms that defer to jaas cannot load login-modules from org.jboss.as.security

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-6767?page=com.atlassian.jira.plugin.... ] Brian Stansberry reassigned WFLY-6767: -------------------------------------- Component/s: Security Assignee: Darran Lofthouse > security-realms that defer to jaas cannot load login-modules from org.jboss.as.security > ---------------------------------------------------------------------------------------- > > Key: WFLY-6767 > URL: https://issues.jboss.org/browse/WFLY-6767 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Derek Horton > Assignee: Darran Lofthouse > > security-realms that defer to jaas cannot load login-modules from org.jboss.as.security. The configuration looks like the following: > <security-realm name="ManagementRealm"> > <authentication> > <jaas name="jmx-console"/> > </authentication> > <authorization map-groups-to-roles="false"> > <properties path="mgmt-groups.properties" relative-to="jboss.server.config.dir"/> > </authorization> > </security-realm> > <security-domain name="jmx-console" cache-type="default"> > <authentication> > <login-module code="RealmUsersRoles" flag="required"> > <module-option name="rolesProperties" value="file://${jboss.server.config.dir}/rolesmapping.properties"/> > <module-option name="usersProperties" value="file://${jboss.server.config.dir}/rolesmapping.properties"/> > </login-module> > </authentication> > </security-domain> > The following error is logged during the authentication attempt: > 2016-06-23 11:17:27,680 DEBUG [org.jboss.security] (management task-1) PBOX00206: Login failure: javax.security.auth.login.LoginException: unable to find LoginModule class: org.jboss.as.security.RealmDirectLoginModule from [Module "org.jboss.as.server:main" from local module loader @42f30e0a (finder: local module finder @24273305 (roots: /home/dehort/dev/java/jboss-eap-7.0.0/modules,/home/dehort/dev/java/jboss-eap-7.0.0/modules/system/layers/base))] > at javax.security.auth.login.LoginContext.invoke(LoginContext.java:794) > at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195) > at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682) > at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680) > at java.security.AccessController.doPrivileged(Native Method) > at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) > at javax.security.auth.login.LoginContext.login(LoginContext.java:587) > at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:406) > at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345) > at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:323) > at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146) > at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:406) > at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:367) > at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:347) > at org.jboss.as.domain.management.security.JaasCallbackHandler.handle(JaasCallbackHandler.java:174) > at org.jboss.as.domain.management.security.SecurityRealmService$1.handle(SecurityRealmService.java:175) > at org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:162) > at org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:141) > at io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:161) > at org.jboss.as.domain.http.server.security.AuthenticationMechanismWrapper.authenticate(AuthenticationMechanismWrapper.java:52) > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233) > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250) > at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219) > at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121) > at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96) > at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89) > at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

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 July 2016