October 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-7382) Build tools 1.1.7.Final

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7382?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-7382: ------------------------------ Description: This is required to remove jandex > Build tools 1.1.7.Final > ----------------------- > > Key: WFLY-7382 > URL: https://issues.jboss.org/browse/WFLY-7382 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Stuart Douglas > Assignee: Stuart Douglas > > This is required to remove jandex -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7382) Build tools 1.1.7.Final

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7382?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-7382: ------------------------------ Description: This is required to remove jandex from full (was: This is required to remove jandex ) > Build tools 1.1.7.Final > ----------------------- > > Key: WFLY-7382 > URL: https://issues.jboss.org/browse/WFLY-7382 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Stuart Douglas > Assignee: Stuart Douglas > > This is required to remove jandex from full -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7382) Build tools 1.1.7.Final

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7382?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-7382: --------------------------------- Assignee: Tomaz Cerar (was: Stuart Douglas) > Build tools 1.1.7.Final > ----------------------- > > Key: WFLY-7382 > URL: https://issues.jboss.org/browse/WFLY-7382 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Stuart Douglas > Assignee: Tomaz Cerar > > This is required to remove jandex from full -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7386) JGroups channels should only use JMX if the associated capability is available.

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-7386: ---------------------------------- Summary: JGroups channels should only use JMX if the associated capability is available. Key: WFLY-7386 URL: https://issues.jboss.org/browse/WFLY-7386 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.1.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7387) Infinispan cache containers should only use JMX if the associated capability is available.

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-7387: ---------------------------------- Summary: Infinispan cache containers should only use JMX if the associated capability is available. Key: WFLY-7387 URL: https://issues.jboss.org/browse/WFLY-7387 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.1.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7343) NPE in elytron SPNEGO implementation in exceptional states

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-7343?page=com.atlassian.jira.plugin.... ] Jan Kalina reassigned WFLY-7343: -------------------------------- Assignee: Jan Kalina > NPE in elytron SPNEGO implementation in exceptional states > ---------------------------------------------------------- > > Key: WFLY-7343 > URL: https://issues.jboss.org/browse/WFLY-7343 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Critical > > Http response code 500 + excpetion in server log: > {code} > 21:40:40,640 ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /secured-webapp/secure/index.jsp: java.lang.NullPointerException > at org.wildfly.security.http.impl.SpnegoAuthenticationMechanism.authorizeEstablishedContext(SpnegoAuthenticationMechanism.java:177) > at org.wildfly.security.http.impl.SpnegoAuthenticationMechanism.evaluateRequest(SpnegoAuthenticationMechanism.java:128) > at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115) > at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90) > at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74) > at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55) > at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810) > 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) > {code} > I have hit this in two situations so far > * accessing with kerberos ticket from another realm. E.g. application server is set for realm JBOSS.ORG, but client is jduke(a)REDHAT.COM > ** For this situation is http response code 500 disputable, as it could be viewed as problem of client. Client can change ticket and authentication can be performed just fine. > * misconfiguration e.g. wrong kdc in krb5.conf > Provide some meaningful error message. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1898) Defining protocol of ssl config in security realm to incorrect value results in broken https

by Radim Hatlapatka (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1898?page=com.atlassian.jira.plugi... ] Radim Hatlapatka commented on WFCORE-1898: ------------------------------------------ [~dlofthouse] thanks, I will remember that. > Defining protocol of ssl config in security realm to incorrect value results in broken https > -------------------------------------------------------------------------------------------- > > Key: WFCORE-1898 > URL: https://issues.jboss.org/browse/WFCORE-1898 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management, Security > Affects Versions: 3.0.0.Alpha10 > Reporter: Radim Hatlapatka > Assignee: Brian Stansberry > Labels: user_experience > > If I define protocol to invalid value, it passes with success even though after reload it results in failure as such protocol isn't available. > It would be great if the value would be checked for proper values and fail the operation when incorrect value is provided. > E.g. this command {{/core-service=management/security-realm=ApplicationRealm/server-identity=ssl:write-attribute(name=protocol, value=ABC)}} should fail, but it passes, resulting that when doing reload https-listener and all dependent services fail to start > It would be beneficial to detect the incorrect value during the value update and rollback in case of invalid value being provided. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1898) Defining protocol of ssl config in security realm to incorrect value results in broken https

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1898?page=com.atlassian.jira.plugi... ] Darran Lofthouse commented on WFCORE-1898: ------------------------------------------ [~rhatlapa] FYI any issues relating to the legacy security realms should be created under the WFCORE project instead of WFLY. > Defining protocol of ssl config in security realm to incorrect value results in broken https > -------------------------------------------------------------------------------------------- > > Key: WFCORE-1898 > URL: https://issues.jboss.org/browse/WFCORE-1898 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management, Security > Affects Versions: 3.0.0.Alpha10 > Reporter: Radim Hatlapatka > Assignee: Brian Stansberry > Labels: user_experience > > If I define protocol to invalid value, it passes with success even though after reload it results in failure as such protocol isn't available. > It would be great if the value would be checked for proper values and fail the operation when incorrect value is provided. > E.g. this command {{/core-service=management/security-realm=ApplicationRealm/server-identity=ssl:write-attribute(name=protocol, value=ABC)}} should fail, but it passes, resulting that when doing reload https-listener and all dependent services fail to start > It would be beneficial to detect the incorrect value during the value update and rollback in case of invalid value being provided. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1898) Defining protocol of ssl config in security realm to incorrect value results in broken https

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1898?page=com.atlassian.jira.plugi... ] Darran Lofthouse moved WFLY-7385 to WFCORE-1898: ------------------------------------------------ Project: WildFly Core (was: WildFly) Key: WFCORE-1898 (was: WFLY-7385) Component/s: Domain Management Security (was: Domain Management) Affects Version/s: 3.0.0.Alpha10 (was: 10.1.0.Final) > Defining protocol of ssl config in security realm to incorrect value results in broken https > -------------------------------------------------------------------------------------------- > > Key: WFCORE-1898 > URL: https://issues.jboss.org/browse/WFCORE-1898 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management, Security > Affects Versions: 3.0.0.Alpha10 > Reporter: Radim Hatlapatka > Assignee: Brian Stansberry > Labels: user_experience > > If I define protocol to invalid value, it passes with success even though after reload it results in failure as such protocol isn't available. > It would be great if the value would be checked for proper values and fail the operation when incorrect value is provided. > E.g. this command {{/core-service=management/security-realm=ApplicationRealm/server-identity=ssl:write-attribute(name=protocol, value=ABC)}} should fail, but it passes, resulting that when doing reload https-listener and all dependent services fail to start > It would be beneficial to detect the incorrect value during the value update and rollback in case of invalid value being provided. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7385) Defining protocol of ssl config in security realm to incorrect value results in broken https

by Radim Hatlapatka (JIRA)

Radim Hatlapatka created WFLY-7385: -------------------------------------- Summary: Defining protocol of ssl config in security realm to incorrect value results in broken https Key: WFLY-7385 URL: https://issues.jboss.org/browse/WFLY-7385 Project: WildFly Issue Type: Enhancement Components: Domain Management Reporter: Radim Hatlapatka Assignee: Brian Stansberry If I define protocol to invalid value, it passes with success even though after reload it results in failure as such protocol isn't available. It would be great if the value would be checked for proper values and fail the operation when incorrect value is provided. E.g. this command {{/core-service=management/security-realm=ApplicationRealm/server-identity=ssl:write-attribute(name=protocol, value=ABC)}} should fail, but it passes, resulting that when doing reload https-listener and all dependent services fail to start It would be beneficial to detect the incorrect value during the value update and rollback in case of invalid value being provided. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2016