April 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1313) User with slash or backslash char in LDAP name cannot log in through security-realm

by Lin Gao (Jira)

[ https://issues.redhat.com/browse/WFCORE-1313?page=com.atlassian.jira.plug... ] Lin Gao reopened WFCORE-1313: ----------------------------- Reopen it because it still reproduced in latest wildfly master > User with slash or backslash char in LDAP name cannot log in through security-realm > ----------------------------------------------------------------------------------- > > Key: WFCORE-1313 > URL: https://issues.redhat.com/browse/WFCORE-1313 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > Assignee: Lin Gao > Priority: Minor > Attachments: users.ldif > > > According to LDAP specification [1], DN can contain slash char without escaping or escaped backslash, etc. > I am not able to log in to management console with username "Slash/Char" or "Back\Slash". But I would be able to log in there. > I can see this in Wireshark > *Slash/Char* > {code} > LDAPMessage bindRequest(1) ""uid=Slash/Char",ou=People,o=LdapRealmSpecialNameManualTest7d339efa,o=primary,dc=jboss,dc=org" simple > LDAPMessage bindResponse(1) invalidDNSyntax (Incorrect DN given : "uid=Slash/Char",ou=People,o=LdapRealmSpecialNameManualTest7d339efa,o=primary,dc=jboss,dc=org (0x22 0x75 0x69 0x64 0x3D 0x53 0x6C 0x61 0x73 0x68 0x2F 0x43 0x68 0x61 0x72 0x2 > {code} > You can see there quotation marks around *uid=Slash/Char*. > *Back\Slash* > {code} > LDAPMessage bindRequest(1) "uid=Back\\\Slash,ou=People,o=LdapRealmSpecialNameManualTest7d339efa,o=primary,dc=jboss,dc=org" simple > LDAPMessage bindResponse(1) invalidDNSyntax (Incorrect DN given : uid=Back\\\Slash,ou=People,o=LdapRealmSpecialNameManualTest7d339efa,o=primary,dc=jboss,dc=org (0x75 0x69 0x64 0x3D 0x42 0x61 0x63 0x6B 0x5C 0x5C 0x5C 0x53 0x6C 0x61 0x73 0x6 > {code} > You can see there three backslash chars. > In my opinion problem can be somewhere around this > {code} > javax.naming.NameImpl.stringifyComp(String comp) > {code} > [1] https://tools.ietf.org/html/rfc2253#section-3 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12684) Avoid NPE when reading Artemis cluster status while Artemis broker isn't fully started

by Ranabir Chakraborty (Jira)

[ https://issues.redhat.com/browse/WFLY-12684?page=com.atlassian.jira.plugi... ] Ranabir Chakraborty commented on WFLY-12684: -------------------------------------------- [~ehugonnet] Can you please provide the steps to recreate this issue? > Avoid NPE when reading Artemis cluster status while Artemis broker isn't fully started > --------------------------------------------------------------------------------------- > > Key: WFLY-12684 > URL: https://issues.redhat.com/browse/WFLY-12684 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 18.0.0.Final > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Major > > 11:00:36,718 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("read-attribute") failed - address: ([ > ("subsystem" => "messaging-activemq"), > ("server" => "default"), > ("ha-policy" => "replication-slave") > ]): java.lang.NullPointerException > at org.wildfly.extension.messaging-activemq//org.wildfly.extension.messaging.activemq.ha.HAPolicySynchronizationStatusReadHandler.executeRuntimeStep(HAPolicySynchronizationStatusReadHandler.java:61) > at org.jboss.as.controller@10.0.0.Final//org.jboss.as.controller.AbstractRuntimeOnlyHandler$1.execute(AbstractRuntimeOnlyHandler.java:59) > at org.jboss.as.controller@10.0.0.Final//org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999) -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13221) Remove package-schema cruft from wildfly-feature-pack-build.xml files

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13221?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFLY-13221: ----------------------------------------- [~yersan] I don't recall the history behind this and may not have been involved. But I suspect that before the legacy feature packs were introduced we had hand coded the schemas that got included, which meant a manual decision-making process. And then the legacy feature packs encoded the same result. We ship a lot of libraries some of which may include schemas that are irrelevant to WildFly. It's a valid discussion whether to filter them out. Not super urgent though. :). But a discussion would need to have some data, i.e. what would be included that isn't already. > Remove package-schema cruft from wildfly-feature-pack-build.xml files > --------------------------------------------------------------------- > > Key: WFLY-13221 > URL: https://issues.redhat.com/browse/WFLY-13221 > Project: WildFly > Issue Type: Task > Components: Build System > Reporter: Brian Stansberry > Assignee: Yeray Borges Santana > Priority: Minor > > The various wildfly-feature-pack-build.xml files include 'package-schemas' elements. AIUI the children of those elements only need to refer to maven groupId for which that specific feature pack provides artifacts with schemas. It does not need to include groupIds for artifacts from other f-ps that the f-p depends on. The WF galleon plugin itself combines those. > So the task is > 1) to clean out cruft, i.e. elements that are related to artifacts from other feature packs. Helps clarify the expected use of these files. > 2) Perhaps in the verifier tests for servlet-dist, ee-dist, dist add verification of the presence of 1 schema from each relevant maven groupId. Guard against schemas suddenly not getting picked up. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5229) DMNValidate mojo fails XMLSchema validation with included models

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-5229?page=com.atlassian.jira.plug... ] Guilherme Gomes updated DROOLS-5229: ------------------------------------ Story Points: 5 > DMNValidate mojo fails XMLSchema validation with included models > ---------------------------------------------------------------- > > Key: DROOLS-5229 > URL: https://issues.redhat.com/browse/DROOLS-5229 > Project: Drools > Issue Type: Bug > Affects Versions: 7.34.0.Final > Reporter: Tracy Hires > Assignee: Guilherme Gomes > Priority: Major > Attachments: ValidateDMN Mojo Failure.png, xml_validation_error.zip > > > The attached DMN decision project was built using Business Central 7.34.0.Final. In this project, the dmn model `Math Functions.dmn` invokes business knowledge model `Quotient` from dmn model `Divide.dmn`. Invoking the ValidateDMN mojo (enabled by default) from the kie-maven-plugin fails XML Validation. One can get past this error by disabling DMNValidation with the following configuration in the pom (though disabling DMNValidation for an XML Schema validation also prevents finding FEEL parser errors): > ``` > <build> > <plugins> > <plugin> > <groupId>org.kie</groupId> > <artifactId>kie-maven-plugin</artifactId> > <version>7.34.0.Final</version> > <extensions>true</extensions> >  > <configuration> > <validateDMN>disabled</validateDMN> > </configuration> > </plugin> > </plugins> > </build> > ``` > When one combines the two dmn models into a single model, the XML Validation succeeds (this example is not supplied, but is trivial to re-build). -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4919) ModelParserUtils should use the --timeout parameter with its embed-server and embed-host-controller calls

by Brian Stansberry (Jira)

Brian Stansberry created WFCORE-4919: ---------------------------------------- Summary: ModelParserUtils should use the --timeout parameter with its embed-server and embed-host-controller calls Key: WFCORE-4919 URL: https://issues.redhat.com/browse/WFCORE-4919 Project: WildFly Core Issue Type: Enhancement Components: Management, Test Suite Reporter: Brian Stansberry Assignee: Jeff Mesnil ModelParserUtils is using embed-server and embed-host-controller. It should include the --timeout parameter to those, with a lengthy value, e.g. 2 minutes, to avoid indefinite hangs like [1] if there's some problem starting the embedded process. [1] https://ci.wildfly.org/viewLog.html?buildId=197876 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4918) Optimize MMR logic within DiscardAttributeChecker.DEFAULT

by Paul Ferraro (Jira)

Paul Ferraro created WFCORE-4918: ------------------------------------ Summary: Optimize MMR logic within DiscardAttributeChecker.DEFAULT Key: WFCORE-4918 URL: https://issues.redhat.com/browse/WFCORE-4918 Project: WildFly Core Issue Type: Task Components: Management Affects Versions: 12.0.0.Beta1 Reporter: Paul Ferraro Assignee: Paul Ferraro See: https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j... https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j... Basically, in order to deal with the possibility of override registrations, calls to an MRR typically result in it internally working up to the root of the MRR tree and then walking back down to the target address. So this: {code:java} ImmutableManagementResourceRegistration registration = context.getResourceRegistrationFromRoot(address); AttributeDefinition definition = registration.getAttributeAccess(PathAddress.EMPTY_ADDRESS, attributeName).getAttributeDefinition(); {code} is less efficient than: {code:java} ImmutableManagementResourceRegistration registration = context.getResourceRegistrationFromRoot(PathAddress.EMPTY_ADDRESS); AttributeDefinition definition = registration.getAttributeAccess(address, attributeName).getAttributeDefinition(); {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4918) Optimize MMR logic within DiscardAttributeChecker.DEFAULT_VALUE

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFCORE-4918?page=com.atlassian.jira.plug... ] Paul Ferraro updated WFCORE-4918: --------------------------------- Summary: Optimize MMR logic within DiscardAttributeChecker.DEFAULT_VALUE (was: Optimize MMR logic within DiscardAttributeChecker.DEFAULT) > Optimize MMR logic within DiscardAttributeChecker.DEFAULT_VALUE > --------------------------------------------------------------- > > Key: WFCORE-4918 > URL: https://issues.redhat.com/browse/WFCORE-4918 > Project: WildFly Core > Issue Type: Task > Components: Management > Affects Versions: 12.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > See: > https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j... > https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j... > Basically, in order to deal with the possibility of override registrations, calls to an MRR typically result in it internally working up to the root of the MRR tree and then walking back down to the target address. So this: > {code:java} > ImmutableManagementResourceRegistration registration = context.getResourceRegistrationFromRoot(address); > AttributeDefinition definition = registration.getAttributeAccess(PathAddress.EMPTY_ADDRESS, attributeName).getAttributeDefinition(); > {code} > is less efficient than: > {code:java} > ImmutableManagementResourceRegistration registration = context.getResourceRegistrationFromRoot(PathAddress.EMPTY_ADDRESS); > AttributeDefinition definition = registration.getAttributeAccess(address, attributeName).getAttributeDefinition(); > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13221) Remove package-schema cruft from wildfly-feature-pack-build.xml files

by Yeray Borges Santana (Jira)

[ https://issues.redhat.com/browse/WFLY-13221?page=com.atlassian.jira.plugi... ] Yeray Borges Santana commented on WFLY-13221: --------------------------------------------- I don't get at all the point of using this package schema declaration to filter out schemas that are included in the current feature pack. Initially, sounds logical to me to include in docs/schema any xsd included in any jar file of my feature pack. However, we are filtering them out and remove completely the package-schemas in the {{wildfly-feature-pack-build.xml}} does not include all. Me as a feature pack consumer would rather expect to find out all xsd included by the feature pack modules under docs/schema. I don't get at all why we are indeed filtering them, won't be easier to include all instead of selectively decide what is included? I suppose the response comes from historical reasons since legacy feature packs were also filtering them. [~brian.stansberry] if you have an argument to this, I would like to know the reason, thanks. > Remove package-schema cruft from wildfly-feature-pack-build.xml files > --------------------------------------------------------------------- > > Key: WFLY-13221 > URL: https://issues.redhat.com/browse/WFLY-13221 > Project: WildFly > Issue Type: Task > Components: Build System > Reporter: Brian Stansberry > Assignee: Yeray Borges Santana > Priority: Minor > > The various wildfly-feature-pack-build.xml files include 'package-schemas' elements. AIUI the children of those elements only need to refer to maven groupId for which that specific feature pack provides artifacts with schemas. It does not need to include groupIds for artifacts from other f-ps that the f-p depends on. The WF galleon plugin itself combines those. > So the task is > 1) to clean out cruft, i.e. elements that are related to artifacts from other feature packs. Helps clarify the expected use of these files. > 2) Perhaps in the verifier tests for servlet-dist, ee-dist, dist add verification of the presence of 1 schema from each relevant maven groupId. Guard against schemas suddenly not getting picked up. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13221) Remove package-schema cruft from wildfly-feature-pack-build.xml files

by Yeray Borges Santana (Jira)

[ https://issues.redhat.com/browse/WFLY-13221?page=com.atlassian.jira.plugi... ] Yeray Borges Santana updated WFLY-13221: ---------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/13211 > Remove package-schema cruft from wildfly-feature-pack-build.xml files > --------------------------------------------------------------------- > > Key: WFLY-13221 > URL: https://issues.redhat.com/browse/WFLY-13221 > Project: WildFly > Issue Type: Task > Components: Build System > Reporter: Brian Stansberry > Assignee: Yeray Borges Santana > Priority: Minor > > The various wildfly-feature-pack-build.xml files include 'package-schemas' elements. AIUI the children of those elements only need to refer to maven groupId for which that specific feature pack provides artifacts with schemas. It does not need to include groupIds for artifacts from other f-ps that the f-p depends on. The WF galleon plugin itself combines those. > So the task is > 1) to clean out cruft, i.e. elements that are related to artifacts from other feature packs. Helps clarify the expected use of these files. > 2) Perhaps in the verifier tests for servlet-dist, ee-dist, dist add verification of the presence of 1 schema from each relevant maven groupId. Guard against schemas suddenly not getting picked up. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13375) JNDI view does not show implementation classes for connection factories and destinations registered by 3rd party resource adapters

by Parul Sharma (Jira)

[ https://issues.redhat.com/browse/WFLY-13375?page=com.atlassian.jira.plugi... ] Parul Sharma moved JBEAP-19214 to WFLY-13375: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-13375 (was: JBEAP-19214) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Naming (was: Naming) Affects Version/s: (was: 7.3.0.GA) (was: 7.2.7.GA) > JNDI view does not show implementation classes for connection factories and destinations registered by 3rd party resource adapters > ----------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-13375 > URL: https://issues.redhat.com/browse/WFLY-13375 > Project: WildFly > Issue Type: Bug > Components: Naming > Reporter: Parul Sharma > Assignee: Parul Sharma > Priority: Major > Attachments: standalone-full.xml, wmq.jmsra.rar > > > If connection factory or JMS destination is configured for third party resource adapter (like IBMMQ 8/9, AMQ 6) then the {{value}} for registered implementation class is {{?}} - see: > {code} > [standalone@localhost:9990 /] /subsystem=naming:jndi-view > { > "outcome" => "success", > "result" => { > "java: contexts" => { > "java:" => { > ... > }, > "jms" => { > "class-name" => "javax.naming.Context", > "children" => { > "CF" => { > "class-name" => "java.lang.Object", > "value" => "?" > }, > "NmvtisSendQ" => { > "class-name" => "java.lang.Object", > "value" => "?" > }, > "topic" => { > "class-name" => "javax.naming.Context", > "children" => { > "T1RHEL6X86_64DYNAMICLARGEOPENJDK18" => { > "class-name" => "java.lang.Object", > "value" => "?" > }, > "T2RHEL6X86_64DYNAMICLARGEOPENJDK18" => { > "class-name" => "java.lang.Object", > "value" => "?" > } > } > } > {code} > There should be provided valid {{value}}, for example {{com.ibm.mq.connector.outbound.ManagedConnectionFactoryImpl}} for "CF" connection factory for IBMMQ. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2020