[JBoss JIRA] (WFCORE-4820) Error: WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFCORE-4820?page=com.atlassian.jira.plug... ]
Darran Lofthouse commented on WFCORE-4820:
------------------------------------------
At the moment this does seem to be broken in WildFly 18 with the only workaround being migrating to an Elytron based configuration - presently looking at options for a fix in WildFly 19.
> Error: WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-4820
> URL: https://issues.redhat.com/browse/WFCORE-4820
> Project: WildFly Core
> Issue Type: Bug
> Components: Management, Security
> Affects Versions: 10.0.3.Final
> Reporter: Mark Sanchez
> Assignee: Darran Lofthouse
> Priority: Major
>
> error:
> WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
> We get an error with the following ldap configuration. This works for version 17.
> <security-realm name="ldap_security_realm">
> <server-identities>
> <ssl>
> <engine enabled-protocols="TLSv1.2"/>
> <keystore path="/opt/app/workload/jboss/ssl_jboss/psftest2s.jboss.keystore" keystore-password="${VAULT::ssl_cert::password::1}"/>
> </ssl>
> </server-identities>
> <authentication>
> <ldap connection="testLdap" base-dn="dc=test,dc=sbc,dc=com" recursive="true">
> <username-filter attribute="samaccountname"/>
> </ldap>
> </authentication>
> </security-realm>
> </security-realms>
> <outbound-connections>
> <ldap name="testLdap" url="ldap://its-ad-ldap.it.test.com:636" search-dn="CN=mxxxxxx,OU=GenericID,OU=testUsers,DC=testServices,DC=test,DC=com" search-credential="${VAULT::ldap_searchdn::password::1}" security-realm="ldap_security_realm"/>
> </outbound-connections>
> <management-interfaces>
> <http-interface security-realm="ldap_security_realm">
> <http-upgrade enabled="true"/>
> <socket interface="management" port="${jboss.management.http.port:9990}"/>
> </http-interface>
> </management-interfaces>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFCORE-4820) Error: WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
by Mark Sanchez (Jira)
[ https://issues.redhat.com/browse/WFCORE-4820?page=com.atlassian.jira.plug... ]
Mark Sanchez commented on WFCORE-4820:
--------------------------------------
Any Status?
> Error: WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-4820
> URL: https://issues.redhat.com/browse/WFCORE-4820
> Project: WildFly Core
> Issue Type: Bug
> Components: Management, Security
> Affects Versions: 10.0.3.Final
> Reporter: Mark Sanchez
> Assignee: Darran Lofthouse
> Priority: Major
>
> error:
> WFLYDM0042: Multiple CallbackHandlerServices for the same mechanism (PLAIN)
> We get an error with the following ldap configuration. This works for version 17.
> <security-realm name="ldap_security_realm">
> <server-identities>
> <ssl>
> <engine enabled-protocols="TLSv1.2"/>
> <keystore path="/opt/app/workload/jboss/ssl_jboss/psftest2s.jboss.keystore" keystore-password="${VAULT::ssl_cert::password::1}"/>
> </ssl>
> </server-identities>
> <authentication>
> <ldap connection="testLdap" base-dn="dc=test,dc=sbc,dc=com" recursive="true">
> <username-filter attribute="samaccountname"/>
> </ldap>
> </authentication>
> </security-realm>
> </security-realms>
> <outbound-connections>
> <ldap name="testLdap" url="ldap://its-ad-ldap.it.test.com:636" search-dn="CN=mxxxxxx,OU=GenericID,OU=testUsers,DC=testServices,DC=test,DC=com" search-credential="${VAULT::ldap_searchdn::password::1}" security-realm="ldap_security_realm"/>
> </outbound-connections>
> <management-interfaces>
> <http-interface security-realm="ldap_security_realm">
> <http-upgrade enabled="true"/>
> <socket interface="management" port="${jboss.management.http.port:9990}"/>
> </http-interface>
> </management-interfaces>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (DROOLS-4988) Test Scenario: improve DMN validation
by Daniele Zonca (Jira)
[ https://issues.redhat.com/browse/DROOLS-4988?page=com.atlassian.jira.plug... ]
Daniele Zonca updated DROOLS-4988:
----------------------------------
Description: Add a check to verify if a simple type has been changed to a structured type. Please consider expression columns too (was: Add a check to verify if a simple type has been changed to a complex type. Please consider expression columns too)
> Test Scenario: improve DMN validation
> -------------------------------------
>
> Key: DROOLS-4988
> URL: https://issues.redhat.com/browse/DROOLS-4988
> Project: Drools
> Issue Type: Enhancement
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: Yeser Amer
> Priority: Major
> Labels: drools-tools
>
> Add a check to verify if a simple type has been changed to a structured type. Please consider expression columns too
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFCORE-4780) Stax maxAttributeSize is only vaguely respected
by Ivo Studensky (Jira)
[ https://issues.redhat.com/browse/WFCORE-4780?page=com.atlassian.jira.plug... ]
Ivo Studensky resolved WFCORE-4780.
-----------------------------------
Resolution: Done
> Stax maxAttributeSize is only vaguely respected
> -----------------------------------------------
>
> Key: WFCORE-4780
> URL: https://issues.redhat.com/browse/WFCORE-4780
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Ilia Vassilev
> Assignee: Ivo Studensky
> Priority: Major
>
> System property org.apache.cxf.stax.maxAttributeSize only vaguely limits attribute values. If I set the property to 5000 I can send up to 8295 characters in an attribute value without EAP denying the request.
> Reviewing the source code for woodstox reveal that the limit is checked against the size of the buffer before the last buffer expansion. After 2459 characters the buffer is grown to 3687. After 5531 characters the limit is checked against 3687 instead of 5531 and not until 8296 characters is the limit checked against the previous buffer size 5531 which is larger than 5000.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months