[JBoss JIRA] (ELY-1151) Empty authorization name for Digest mechanism causes authentication fail
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1151?page=com.atlassian.jira.plugin.s... ]
Jan Kalina reopened ELY-1151:
-----------------------------
> Empty authorization name for Digest mechanism causes authentication fail
> ------------------------------------------------------------------------
>
> Key: ELY-1151
> URL: https://issues.jboss.org/browse/ELY-1151
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta38
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Priority: Blocker
> Fix For: 1.1.0.Beta44
>
>
> SASL specification says about Authorization Identity String [1]:
> {quote}
> If the authorization identity string is absent, the client is requesting to act as the identity the server associates with the client's credentials. *An empty string is equivalent to an absent authorization identity.*
> {quote}
> In case when authentication configuration includes empty name for authorization name then authentication fail. In correct behavior authentication name should be used if authorization name is empty string.
> It is caused by passing empty {{defaultName}} to {{NameCallback}} constructor which results to {{IllegalArgumentException}}. Condition in [2] checks only non-null value of {{authorizationId}} but it seems it should also check empty name.
> It can be reproduced with correctly set wildfly-config.xml (i.e. configuration where authentication succeed) - in case {{set-authorization-name}} element with empty string is added to this configuration file then authentication starts to fail.
> The same issue can occurs for every supported SASL mechanism. In needs to be revisited.
> We request blocker flag since current behavior violates SASL specification.
> [1] https://tools.ietf.org/html/rfc4422#section-3.4.1
> [2] https://github.com/wildfly-security/wildfly-elytron/blob/596f25e853c8fbae...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 4 months
[JBoss JIRA] (WFCORE-2885) list-remove operation succeeds when removing non-existent item
by Michal Petrov (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2885?page=com.atlassian.jira.plugi... ]
Michal Petrov commented on WFCORE-2885:
---------------------------------------
As I said there are some remove-* operations that do fail (e.g. "remove-namespace") and some that don't. With WFCORE-2880 filed I wasn't sure what is the intended behavior of these.
> list-remove operation succeeds when removing non-existent item
> --------------------------------------------------------------
>
> Key: WFCORE-2885
> URL: https://issues.jboss.org/browse/WFCORE-2885
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Michal Petrov
> Assignee: Michal Petrov
>
> When removing an item from a list the operation should fail if the item doesn't exist. E.g.
> {code}
> /subsystem=logging/root-logger=ROOT:list-remove(name=handlers,value="ABC")
> {code}
> the operation already fails when using an invalid index.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 4 months
[JBoss JIRA] (WFCORE-2626) Network interface selection criteria is not working for a duplicate IP addresses but one is down
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2626?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on WFCORE-2626:
-------------------------------------------------
Radovan STANCEL <rstancel(a)redhat.com> changed the Status of [bug 1442325|https://bugzilla.redhat.com/show_bug.cgi?id=1442325] from POST to MODIFIED
> Network interface selection criteria is not working for a duplicate IP addresses but one is down
> ------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2626
> URL: https://issues.jboss.org/browse/WFCORE-2626
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Environment: On Fedora 24 KVM instance, I added 2 extra NICs those are recognized as ens9 and ens10. Both have 192.168.1.1 but one is down.
> {code}
> # ip address show
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> valid_lft forever preferred_lft forever
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
> 2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
> link/ether 52:54:00:ca:86:e2 brd ff:ff:ff:ff:ff:ff
> inet 192.168.122.117/24 brd 192.168.122.255 scope global dynamic ens3
> valid_lft 3483sec preferred_lft 3483sec
> inet6 fe80::782d:5d87:243d:917f/64 scope link
> valid_lft forever preferred_lft forever
> 3: ens9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
> link/ether 52:54:00:ee:c6:16 brd ff:ff:ff:ff:ff:ff
> inet 192.168.1.1/24 scope global ens9
> valid_lft forever preferred_lft forever
> 4: ens10: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
> link/ether 52:54:00:52:78:ca brd ff:ff:ff:ff:ff:ff
> inet 192.168.1.1/24 scope global ens10
> valid_lft forever preferred_lft forever
> {code}
> Reporter: Osamu Nagano
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Beta16
>
>
> In the standalone.xml, there are {{<up/>}} criterion which is sufficient to identify a unique NIC under the environment described above.
> {code}
> <interfaces>
> <interface name="management">
> <up/>
> <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
> </interface>
> <interface name="public">
> <up/>
> <inet-address value="${jboss.bind.address:127.0.0.1}"/>
> </interface>
> </interfaces>
> {code}
> But it says "ambiguous". WildFly 10.1.0.Final doesn't show this error.
> {code}
> # $JBOSS_HOME/bin/standalone.sh -b 192.168.1.1 -bmanagement=192.168.1.1
> ...
> 04:38:52,839 WARN [org.jboss.as.controller] (MSC service thread 1-3) WFLYCTL0023: Value '192.168.1.1' for interface selection criteria 'inet-address' is ambiguous, as more than one address or network interface available on the machine matches it. Because of this ambiguity,
> no address will be selected as a match. Matching addresses: [/192.168.1.1]. Matching network interfaces: [ens9, ens10].
> 04:38:52,840 WARN [org.jboss.as.controller] (MSC service thread 1-4) WFLYCTL0023: Value '192.168.1.1' for interface selection criteria 'inet-address' is ambiguous, as more than one address or network interface available on the machine matches it. Because of this ambiguity,
> no address will be selected as a match. Matching addresses: [/192.168.1.1]. Matching network interfaces: [ens9, ens10].
> 04:38:52,840 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.network.public: org.jboss.msc.service.StartException in service jboss.network.public: WFLYSRV0082: failed to resolve interface public
> at org.jboss.as.server.services.net.NetworkInterfaceService.start(NetworkInterfaceService.java:91)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> 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)
> 04:38:52,841 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.network.management: org.jboss.msc.service.StartException in service jboss.network.management: WFLYSRV0082: failed to resolve interface management
> at org.jboss.as.server.services.net.NetworkInterfaceService.start(NetworkInterfaceService.java:91)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> 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}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 4 months
[JBoss JIRA] (WFLY-8458) NPE when MBean does not have no-arg constructor
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-8458?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-8458:
-----------------------------------------------
Radovan STANCEL <rstancel(a)redhat.com> changed the Status of [bug 1436390|https://bugzilla.redhat.com/show_bug.cgi?id=1436390] from POST to MODIFIED
> NPE when MBean does not have no-arg constructor
> -----------------------------------------------
>
> Key: WFLY-8458
> URL: https://issues.jboss.org/browse/WFLY-8458
> Project: WildFly
> Issue Type: Bug
> Components: JMX, Server
> Affects Versions: 11.0.0.Alpha1
> Reporter: Chao Wang
> Assignee: Chao Wang
> Fix For: 11.0.0.Beta1
>
>
> NPE when MBean does not have no-arg constructor, it should log an error message indicating the issue rather than NPE
> {code}
> 15:05:48,605 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."jboss-helloworld-dynamicmbean-helloworld-mbean-service.sar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-helloworld-dynamicmbean-helloworld-mbean-service.sar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "jboss-helloworld-dynamicmbean-helloworld-mbean-service.sar"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> 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)
> Caused by: java.lang.IllegalArgumentException: WFLYSAR0004: Class not instantiated
> at org.jboss.as.service.ReflectionUtils.newInstance(ReflectionUtils.java:133)
> at org.jboss.as.service.ParsedServiceDeploymentProcessor.newInstance(ParsedServiceDeploymentProcessor.java:283)
> at org.jboss.as.service.ParsedServiceDeploymentProcessor.addServices(ParsedServiceDeploymentProcessor.java:129)
> at org.jboss.as.service.ParsedServiceDeploymentProcessor.deploy(ParsedServiceDeploymentProcessor.java:118)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165)
> ... 5 more
> Caused by: java.lang.NullPointerException
> at org.jboss.as.service.ReflectionUtils.newInstance(ReflectionUtils.java:131)
> ... 9 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 4 months
[JBoss JIRA] (WFCORE-2886) remove-handler operation succeeds when removing non-existent handler
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2886?page=com.atlassian.jira.plugi... ]
Brian Stansberry edited comment on WFCORE-2886 at 5/30/17 11:00 AM:
--------------------------------------------------------------------
This probably shouldn't fail either (i.e. same thinking as WFCORE-2885); if it does it is a likely regression. Please get an opinion from [~jamezp].
was (Author: brian.stansberry):
This probably shouldn't fail either; if it does it is a likely regression. Please get an opinion from [~jamezp].
> remove-handler operation succeeds when removing non-existent handler
> --------------------------------------------------------------------
>
> Key: WFCORE-2886
> URL: https://issues.jboss.org/browse/WFCORE-2886
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Michal Petrov
> Assignee: Michal Petrov
>
> When trying to remove a handler that doesn't exist the operation should fail. E.g.
> {code}
> /subsystem=logging/root-logger=ROOT:remove-handler(name="ABC")
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 4 months
[JBoss JIRA] (WFLY-8860) Add optional module dependency for org.springframework.spring to org.apache.cxf.impl
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-8860?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-8860:
--------------------------------------
Component/s: Web Services
Assignee: Alessio Soldano (was: Jason Greene)
> Add optional module dependency for org.springframework.spring to org.apache.cxf.impl
> ------------------------------------------------------------------------------------
>
> Key: WFLY-8860
> URL: https://issues.jboss.org/browse/WFLY-8860
> Project: WildFly
> Issue Type: Enhancement
> Components: Web Services
> Reporter: James Netherton
> Assignee: Alessio Soldano
>
> Similar to WFLY-5532, for our [Camel integration|https://github.com/wildfly-extras/wildfly-camel] the camel-cxf component calls into cxf for Spring namespace handlers. Module {{org.apache.cxf.impl}} exposes a number of resources which have their own Spring namespace handlers. When accessing them (E.g {{org/apache/cxf/transport/http/spring/NamespaceHandler}}), I get:
> {code}
> Caused by: java.lang.NoClassDefFoundError: Failed to link org/apache/cxf/transport/http/spring/NamespaceHandler (Module "org.apache.cxf.impl:main" from local module loader @4c75cab9 (finder: local module finder @1ef7fe8e (roots: /home/james/Projects/git/fork/wildfly-camel/itests/standalone/basic/target/wildfly-10.1.0.Final/modules,/home/james/Projects/git/fork/wildfly-camel/itests/standalone/basic/target/wildfly-10.1.0.Final/modules/system/layers/fuse,/home/james/Projects/git/fork/wildfly-camel/itests/standalone/basic/target/wildfly-10.1.0.Final/modules/system/layers/base))): org/springframework/beans/factory/xml/NamespaceHandlerSupport
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:446)
> at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:274)
> at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:78)
> at org.jboss.modules.Module.loadModuleClass(Module.java:606)
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93)
> at org.springframework.util.ClassUtils.forName(ClassUtils.java:250)
> at org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.resolve(DefaultNamespaceHandlerResolver.java:125)
> ... 19 more
> {code}
> Please can we add an optional dependency for {{org.springframework.spring}} to {{org.apache.cxf.impl}}.
> Cross ref here: https://github.com/wildfly-extras/wildfly-camel/issues/1897
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 4 months
[JBoss JIRA] (WFCORE-2885) list-remove operation succeeds when removing non-existent item
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2885?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-2885:
------------------------------------------
Sorry; I misunderstood in chat. I thought this was about a non-existent resource (i.e. root-logger=ROOT was invalid), not a non-existent element in a collection attribute.
I don't agree this should fail. That would be a breaking behavior change. It wouldn't be strange at all to write a script that removes ABC and then does something else, not really caring whether it is present in the first place, only caring that it isn't present after the remove call.
> list-remove operation succeeds when removing non-existent item
> --------------------------------------------------------------
>
> Key: WFCORE-2885
> URL: https://issues.jboss.org/browse/WFCORE-2885
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Michal Petrov
> Assignee: Michal Petrov
>
> When removing an item from a list the operation should fail if the item doesn't exist. E.g.
> {code}
> /subsystem=logging/root-logger=ROOT:list-remove(name=handlers,value="ABC")
> {code}
> the operation already fails when using an invalid index.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 4 months
[JBoss JIRA] (WFLY-8860) Add optional module dependency for org.springframework.spring to org.apache.cxf.impl
by James Netherton (JIRA)
James Netherton created WFLY-8860:
-------------------------------------
Summary: Add optional module dependency for org.springframework.spring to org.apache.cxf.impl
Key: WFLY-8860
URL: https://issues.jboss.org/browse/WFLY-8860
Project: WildFly
Issue Type: Enhancement
Reporter: James Netherton
Assignee: Jason Greene
Similar to WFLY-5532, for our [Camel integration|https://github.com/wildfly-extras/wildfly-camel] the camel-cxf component calls into cxf for Spring namespace handlers. Module {{org.apache.cxf.impl}} exposes a number of resources which have their own Spring namespace handlers. When accessing them (E.g {{org/apache/cxf/transport/http/spring/NamespaceHandler}}), I get:
{code}
Caused by: java.lang.NoClassDefFoundError: Failed to link org/apache/cxf/transport/http/spring/NamespaceHandler (Module "org.apache.cxf.impl:main" from local module loader @4c75cab9 (finder: local module finder @1ef7fe8e (roots: /home/james/Projects/git/fork/wildfly-camel/itests/standalone/basic/target/wildfly-10.1.0.Final/modules,/home/james/Projects/git/fork/wildfly-camel/itests/standalone/basic/target/wildfly-10.1.0.Final/modules/system/layers/fuse,/home/james/Projects/git/fork/wildfly-camel/itests/standalone/basic/target/wildfly-10.1.0.Final/modules/system/layers/base))): org/springframework/beans/factory/xml/NamespaceHandlerSupport
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:446)
at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:274)
at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:78)
at org.jboss.modules.Module.loadModuleClass(Module.java:606)
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93)
at org.springframework.util.ClassUtils.forName(ClassUtils.java:250)
at org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.resolve(DefaultNamespaceHandlerResolver.java:125)
... 19 more
{code}
Please can we add an optional dependency for {{org.springframework.spring}} to {{org.apache.cxf.impl}}.
Cross ref here: https://github.com/wildfly-extras/wildfly-camel/issues/1897
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 4 months