[JBoss JIRA] (WFCORE-2258) 500 return for nonexistent user in legacy ldap security realm
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2258?page=com.atlassian.jira.plugi... ]
Martin Choma updated WFCORE-2258:
---------------------------------
Description:
In case of securing management interface with ldap in security realm. When nonexistent user is provided, wildfly answers with {{500}} http status code. It is different behaviour compared to wildfly 10.1, which returns {{401}}. I think http status code {{401}} is proper in this situation, because it is client fault (e.g. typo in username) and can be repaired on client side.
{code:title=server.log}
10:49:18,745 TRACE [org.wildfly.security] (management task-10) Handling MechanismInformationCallback
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling AvailableRealmsCallback: realms = [ldap-realm]
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling RealmCallback: selected = [ldap-realm]
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling NameCallback: authenticationName = anil
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Name assigning: [anil], pre-realm rewritten: [anil], realm name: [PLAIN], post realm rewritten: [anil], realm rewritten: [anil]
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Non caching search for 'anil'
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Performing single level search
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Searching for user 'anil' using filter '(uid={0})'.
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Connecting to LDAP with properties ({java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost.localdomain:10389, java.naming.security.principal=uid=admin,ou=system, java.naming.security.credentials=***, java.naming.referral=ignore})
10:49:18,749 WARN [org.apache.directory.server.core.api.interceptor.context.FilteringOperationContext] (pool-7-thread-1) Requested attribute dn does not exist in the schema, it will be ignored
10:49:18,750 TRACE [org.jboss.as.domain.management.security] (management task-10) User 'anil' not found in directory.
{code}
was:
In case of securing management interface with ldap in security realm. When nonexistent user is provided, EAP answers with {{500}} http status code. It is different behaviour compared to wildfly 10.1, which returns {{401}}. I think http status code {{401}} is proper in this situation, because it is client fault (e.g. typo in username) and can be repaired on client side.
{code:title=server.log}
10:49:18,745 TRACE [org.wildfly.security] (management task-10) Handling MechanismInformationCallback
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling AvailableRealmsCallback: realms = [ldap-realm]
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling RealmCallback: selected = [ldap-realm]
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling NameCallback: authenticationName = anil
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Name assigning: [anil], pre-realm rewritten: [anil], realm name: [PLAIN], post realm rewritten: [anil], realm rewritten: [anil]
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Non caching search for 'anil'
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Performing single level search
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Searching for user 'anil' using filter '(uid={0})'.
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Connecting to LDAP with properties ({java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost.localdomain:10389, java.naming.security.principal=uid=admin,ou=system, java.naming.security.credentials=***, java.naming.referral=ignore})
10:49:18,749 WARN [org.apache.directory.server.core.api.interceptor.context.FilteringOperationContext] (pool-7-thread-1) Requested attribute dn does not exist in the schema, it will be ignored
10:49:18,750 TRACE [org.jboss.as.domain.management.security] (management task-10) User 'anil' not found in directory.
{code}
> 500 return for nonexistent user in legacy ldap security realm
> -------------------------------------------------------------
>
> Key: WFCORE-2258
> URL: https://issues.jboss.org/browse/WFCORE-2258
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Blocker
> Labels: eap71_alpha, regression
>
> In case of securing management interface with ldap in security realm. When nonexistent user is provided, wildfly answers with {{500}} http status code. It is different behaviour compared to wildfly 10.1, which returns {{401}}. I think http status code {{401}} is proper in this situation, because it is client fault (e.g. typo in username) and can be repaired on client side.
> {code:title=server.log}
> 10:49:18,745 TRACE [org.wildfly.security] (management task-10) Handling MechanismInformationCallback
> 10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling AvailableRealmsCallback: realms = [ldap-realm]
> 10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling RealmCallback: selected = [ldap-realm]
> 10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling NameCallback: authenticationName = anil
> 10:49:18,746 TRACE [org.wildfly.security] (management task-10) Name assigning: [anil], pre-realm rewritten: [anil], realm name: [PLAIN], post realm rewritten: [anil], realm rewritten: [anil]
> 10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Non caching search for 'anil'
> 10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Performing single level search
> 10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Searching for user 'anil' using filter '(uid={0})'.
> 10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Connecting to LDAP with properties ({java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost.localdomain:10389, java.naming.security.principal=uid=admin,ou=system, java.naming.security.credentials=***, java.naming.referral=ignore})
> 10:49:18,749 WARN [org.apache.directory.server.core.api.interceptor.context.FilteringOperationContext] (pool-7-thread-1) Requested attribute dn does not exist in the schema, it will be ignored
> 10:49:18,750 TRACE [org.jboss.as.domain.management.security] (management task-10) User 'anil' not found in directory.
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2258) 500 return for nonexistent user in legacy ldap security realm
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2258?page=com.atlassian.jira.plugi... ]
Martin Choma updated WFCORE-2258:
---------------------------------
Description:
In case of securing management interface with ldap in security realm. When nonexistent user is provided, EAP answers with {{500}} http status code. It is different behaviour compared to wildfly 10.1, which returns {{401}}. I think http status code {{401}} is proper in this situation, because it is client fault (e.g. typo in username) and can be repaired on client side.
{code:title=server.log}
10:49:18,745 TRACE [org.wildfly.security] (management task-10) Handling MechanismInformationCallback
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling AvailableRealmsCallback: realms = [ldap-realm]
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling RealmCallback: selected = [ldap-realm]
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling NameCallback: authenticationName = anil
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Name assigning: [anil], pre-realm rewritten: [anil], realm name: [PLAIN], post realm rewritten: [anil], realm rewritten: [anil]
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Non caching search for 'anil'
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Performing single level search
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Searching for user 'anil' using filter '(uid={0})'.
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Connecting to LDAP with properties ({java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost.localdomain:10389, java.naming.security.principal=uid=admin,ou=system, java.naming.security.credentials=***, java.naming.referral=ignore})
10:49:18,749 WARN [org.apache.directory.server.core.api.interceptor.context.FilteringOperationContext] (pool-7-thread-1) Requested attribute dn does not exist in the schema, it will be ignored
10:49:18,750 TRACE [org.jboss.as.domain.management.security] (management task-10) User 'anil' not found in directory.
{code}
was:
In case of securing management interface with ldap in security realm. When nonexistent user is provided, EAP answers with {{500}} http status code. It is different behaviour compared to EAP 7.0, which returns {{401}}. I think http status code {{401}} is proper in this situation, because it is client fault (e.g. typo in username) and can be repaired on client side.
{code:title=server.log}
10:49:18,745 TRACE [org.wildfly.security] (management task-10) Handling MechanismInformationCallback
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling AvailableRealmsCallback: realms = [ldap-realm]
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling RealmCallback: selected = [ldap-realm]
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling NameCallback: authenticationName = anil
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Name assigning: [anil], pre-realm rewritten: [anil], realm name: [PLAIN], post realm rewritten: [anil], realm rewritten: [anil]
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Non caching search for 'anil'
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Performing single level search
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Searching for user 'anil' using filter '(uid={0})'.
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Connecting to LDAP with properties ({java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost.localdomain:10389, java.naming.security.principal=uid=admin,ou=system, java.naming.security.credentials=***, java.naming.referral=ignore})
10:49:18,749 WARN [org.apache.directory.server.core.api.interceptor.context.FilteringOperationContext] (pool-7-thread-1) Requested attribute dn does not exist in the schema, it will be ignored
10:49:18,750 TRACE [org.jboss.as.domain.management.security] (management task-10) User 'anil' not found in directory.
{code}
> 500 return for nonexistent user in legacy ldap security realm
> -------------------------------------------------------------
>
> Key: WFCORE-2258
> URL: https://issues.jboss.org/browse/WFCORE-2258
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Blocker
> Labels: eap71_alpha, regression
>
> In case of securing management interface with ldap in security realm. When nonexistent user is provided, EAP answers with {{500}} http status code. It is different behaviour compared to wildfly 10.1, which returns {{401}}. I think http status code {{401}} is proper in this situation, because it is client fault (e.g. typo in username) and can be repaired on client side.
> {code:title=server.log}
> 10:49:18,745 TRACE [org.wildfly.security] (management task-10) Handling MechanismInformationCallback
> 10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling AvailableRealmsCallback: realms = [ldap-realm]
> 10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling RealmCallback: selected = [ldap-realm]
> 10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling NameCallback: authenticationName = anil
> 10:49:18,746 TRACE [org.wildfly.security] (management task-10) Name assigning: [anil], pre-realm rewritten: [anil], realm name: [PLAIN], post realm rewritten: [anil], realm rewritten: [anil]
> 10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Non caching search for 'anil'
> 10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Performing single level search
> 10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Searching for user 'anil' using filter '(uid={0})'.
> 10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Connecting to LDAP with properties ({java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost.localdomain:10389, java.naming.security.principal=uid=admin,ou=system, java.naming.security.credentials=***, java.naming.referral=ignore})
> 10:49:18,749 WARN [org.apache.directory.server.core.api.interceptor.context.FilteringOperationContext] (pool-7-thread-1) Requested attribute dn does not exist in the schema, it will be ignored
> 10:49:18,750 TRACE [org.jboss.as.domain.management.security] (management task-10) User 'anil' not found in directory.
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2257) Missing username in LDAP entry for legacy ldap realm returns 500 instead of 401
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2257?page=com.atlassian.jira.plugi... ]
Ondrej Lukas updated WFCORE-2257:
---------------------------------
Description:
In case when legacy LDAP Realm uses {{username-load}} attribute and its value does not exist in LDAP entry then current implementation returns status code 500. This is different behaviour from WildFly 10 where status code 401 is returned.
This issue can be related to WFCORE-2258 (500 return for nonexistent user in legacy ldap security realm).
was:
In case when legacy LDAP Realm uses {{username-load}} attribute and its value does not exist in LDAP entry then current implementation returns status code 500. This is different behaviour from EAP 7.0.x where status code 401 is returned.
This issue can be related to JBEAP-8106 (500 return for nonexistent user in legacy ldap security realm).
[~dlofthouse] should it be handled as blocker due to regression or is this change intended and we should just cover this change only in release notes?
> Missing username in LDAP entry for legacy ldap realm returns 500 instead of 401
> -------------------------------------------------------------------------------
>
> Key: WFCORE-2257
> URL: https://issues.jboss.org/browse/WFCORE-2257
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
>
> In case when legacy LDAP Realm uses {{username-load}} attribute and its value does not exist in LDAP entry then current implementation returns status code 500. This is different behaviour from WildFly 10 where status code 401 is returned.
> This issue can be related to WFCORE-2258 (500 return for nonexistent user in legacy ldap security realm).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2258) 500 return for nonexistent user in legacy ldap security realm
by Martin Choma (JIRA)
Martin Choma created WFCORE-2258:
------------------------------------
Summary: 500 return for nonexistent user in legacy ldap security realm
Key: WFCORE-2258
URL: https://issues.jboss.org/browse/WFCORE-2258
Project: WildFly Core
Issue Type: Bug
Components: Security
Reporter: Martin Choma
Assignee: Darran Lofthouse
Priority: Blocker
In case of securing management interface with ldap in security realm. When nonexistent user is provided, EAP answers with {{500}} http status code. It is different behaviour compared to EAP 7.0, which returns {{401}}. I think http status code {{401}} is proper in this situation, because it is client fault (e.g. typo in username) and can be repaired on client side.
{code:title=server.log}
10:49:18,745 TRACE [org.wildfly.security] (management task-10) Handling MechanismInformationCallback
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling AvailableRealmsCallback: realms = [ldap-realm]
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling RealmCallback: selected = [ldap-realm]
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Handling NameCallback: authenticationName = anil
10:49:18,746 TRACE [org.wildfly.security] (management task-10) Name assigning: [anil], pre-realm rewritten: [anil], realm name: [PLAIN], post realm rewritten: [anil], realm rewritten: [anil]
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Non caching search for 'anil'
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Performing single level search
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Searching for user 'anil' using filter '(uid={0})'.
10:49:18,746 TRACE [org.jboss.as.domain.management.security] (management task-10) Connecting to LDAP with properties ({java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory, java.naming.provider.url=ldap://localhost.localdomain:10389, java.naming.security.principal=uid=admin,ou=system, java.naming.security.credentials=***, java.naming.referral=ignore})
10:49:18,749 WARN [org.apache.directory.server.core.api.interceptor.context.FilteringOperationContext] (pool-7-thread-1) Requested attribute dn does not exist in the schema, it will be ignored
10:49:18,750 TRACE [org.jboss.as.domain.management.security] (management task-10) User 'anil' not found in directory.
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2257) Missing username in LDAP entry for legacy ldap realm returns 500 instead of 401
by Ondrej Lukas (JIRA)
Ondrej Lukas created WFCORE-2257:
------------------------------------
Summary: Missing username in LDAP entry for legacy ldap realm returns 500 instead of 401
Key: WFCORE-2257
URL: https://issues.jboss.org/browse/WFCORE-2257
Project: WildFly Core
Issue Type: Bug
Components: Security
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
In case when legacy LDAP Realm uses {{username-load}} attribute and its value does not exist in LDAP entry then current implementation returns status code 500. This is different behaviour from EAP 7.0.x where status code 401 is returned.
This issue can be related to JBEAP-8106 (500 return for nonexistent user in legacy ldap security realm).
[~dlofthouse] should it be handled as blocker due to regression or is this change intended and we should just cover this change only in release notes?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-3858) Infinispan cache configuration is not always applied to security-domain
by Hisanobu Okuda (JIRA)
[ https://issues.jboss.org/browse/WFLY-3858?page=com.atlassian.jira.plugin.... ]
Hisanobu Okuda updated WFLY-3858:
---------------------------------
> Infinispan cache configuration is not always applied to security-domain
> -----------------------------------------------------------------------
>
> Key: WFLY-3858
> URL: https://issues.jboss.org/browse/WFLY-3858
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 8.1.0.Final
> Reporter: Robert Tuck
> Assignee: Darran Lofthouse
> Attachments: debugger output.txt
>
>
> On Wildfly 8.1.0.Final, I have the following standalone-ha.xml:
> <subsystem xmlns="urn:jboss:domain:infinispan:2.0">
> ...
> <cache-container name="security" default-cache="auth-cache" start="EAGER">
> <transport cluster="${cluster.name}_SEC" lock-timeout="60000"/>
> <replicated-cache name="auth-cache" batching="true" mode="ASYNC">
> <eviction strategy="LRU" max-entries="10000"/>
> <expiration lifespan="60000"/>
> </replicated-cache>
> </cache-container>
> </subsystem>
> ...
> <subsystem xmlns="urn:jboss:domain:security:1.2">
> <security-domains>
> ...
> <security-domain name="OAuth-Consumer" cache-type="infinispan">
> <authentication>
> <login-module code="com.idbs.ewb.server.auth.module.OAuthConsumerLoginModule" flag="sufficient"
> module="deployment.ewb-server-ear.ear">
> <module-option name="allowedConsumerAuthFailures" value="-1"/>
> <module-option name="consumerLoginFailureTimeoutMs" value="3000"/>
> </login-module>
> </authentication>
> </security-domain>
> </security-domains>
> </subsystem>
> After startup the OAuth-Consumer security domain cache "auth-cache" is not always configured with the specified settings (~50% of the time). This can be verified by monitoring the jboss.infinispan nodes with JConsole and retrieving the cache settings, and tracking the cache hits during logins. This shows that succesful logins are cached but do not expire after the expected 60s, and that the expiration lifespan is set to -1 rather than 60000, as are eviction max entries.
> After some debugging I have narrowed down the problem to some code that gets called from inside org.jboss.as.security.plugins.JNDIBasedSecurityManagement:
> public SecurityDomainContext createSecurityDomainContext(String securityDomain, Object cacheFactory) throws Exception {
> log.debugf("Creating SDC for domain=" + securityDomain);
> AuthenticationManager am = createAuthenticationManager(securityDomain);
> // create authentication cache
> if (cacheFactory instanceof EmbeddedCacheManager) {
> EmbeddedCacheManager cacheManager = EmbeddedCacheManager.class.cast(cacheFactory);
> @SuppressWarnings("rawtypes")
> Cache cache = null;
> if (cacheManager != null) {
> // TODO override global settings with security domain specific
> ConfigurationBuilder builder = new ConfigurationBuilder();
> Configuration baseCfg = cacheManager.getCacheConfiguration("auth-cache");
> ^^^^ This call here doesn’t always return the correct configuration, baseCfg is then null.
> if (baseCfg != null) {
> builder.read(baseCfg);
> }
> cacheManager.defineConfiguration(securityDomain, builder.build());
> cache = cacheManager.getCache(securityDomain);
> }
> if (cache != null && am instanceof CacheableManager) {
> @SuppressWarnings({ "unchecked", "rawtypes" })
> CacheableManager<Map, Principal> cm = (CacheableManager<Map, Principal>) am;
> cm.setCache(cache);
> }
> } else if (cacheFactory instanceof DefaultAuthenticationCacheFactory) {
> <…>
> }
> getCacheConfiguration(String) is implemented inside org.infinispan.manager.DefaultCacheManager:
> @Override
> public Configuration getCacheConfiguration(String name) {
> Configuration configuration = configurationOverrides.get(name);
> if (configuration == null && cacheExists(name)) {
> return defaultConfiguration;
> }
> return configuration;
> }
> Seems like the condition configuration == null occurs when the cache doesn’t exist, therefore it returns null. This appears to be a race condition between this code and where it gets registered in wireAndStartCache(String).
>
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2253) Some AttributeDefinition instances are configured with default values but say they are required
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2253?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-2253:
----------------------------------------
Assignee: Brian Stansberry
> Some AttributeDefinition instances are configured with default values but say they are required
> -----------------------------------------------------------------------------------------------
>
> Key: WFCORE-2253
> URL: https://issues.jboss.org/browse/WFCORE-2253
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> An AD with a default value does not require the user to set it, so configuring it with required = true fka allowNull = false is incorrect. WFCORE-2252 proposes to reject these. This is to clean them up first.
> Note that for any such attributes, if they existed in a previous release a transformer must be written to go along with a change to required=false. Even though they had a default before, the required=true setting made it as if it didn't exist, so this change is the same as adding a default
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-8010) Write a test for DataSources with Elytron
by Flavia Rainone (JIRA)
Flavia Rainone created WFLY-8010:
------------------------------------
Summary: Write a test for DataSources with Elytron
Key: WFLY-8010
URL: https://issues.jboss.org/browse/WFLY-8010
Project: WildFly
Issue Type: Enhancement
Components: JCA
Reporter: Flavia Rainone
Assignee: Stefano Maestri
Write a basic test case to make sure everything needed to make DataSources + Elytron work is in place.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-8007) Replace WorkManager elytron-enabled atttribute by elytron-security-domain
by Flavia Rainone (JIRA)
[ https://issues.jboss.org/browse/WFLY-8007?page=com.atlassian.jira.plugin.... ]
Flavia Rainone reassigned WFLY-8007:
------------------------------------
Assignee: James Perkins (was: Stefano Maestri)
[~jamezp], do you think you will have time to look into this other Capability-related issue before the next release? Let me know if that's not the case, either I or [~maeste] will work on this Jira. Thanks a lot!
> Replace WorkManager elytron-enabled atttribute by elytron-security-domain
> -------------------------------------------------------------------------
>
> Key: WFLY-8007
> URL: https://issues.jboss.org/browse/WFLY-8007
> Project: WildFly
> Issue Type: Enhancement
> Components: JCA
> Reporter: Flavia Rainone
> Assignee: James Perkins
>
> Right now the elytron-enabled attribute does not allow the dependency on the security domain capability. We need to replace it by elytron-security-domain and have the capability dependency sorted out.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-1620) Upgrade slf4j from version 1.7.7.jbossorg-1 to 1.7.22
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1620?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1620:
-------------------------------------
Fix Version/s: 2.2.1.Final
> Upgrade slf4j from version 1.7.7.jbossorg-1 to 1.7.22
> -----------------------------------------------------
>
> Key: WFCORE-1620
> URL: https://issues.jboss.org/browse/WFCORE-1620
> Project: WildFly Core
> Issue Type: Component Upgrade
> Components: Logging
> Reporter: James Perkins
> Assignee: Frank Langelage
> Fix For: 3.0.0.Alpha18, 2.2.1.Final
>
>
> There should no longer be a need for the forked version. The fix for [SLF4J-167|http://jira.qos.ch/browse/SLF4J-167] should be in version 1.7.14 with some additional fixes for replaying the previously lost logs.
> [Quote from comment on JIRA|http://jira.qos.ch/browse/SLF4J-167?focusedCommentId=17048&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17048]
> {quote}
> The problem of lost logs during initialization in a multi-threaded application is solved by storing and replaying the logs which would be otherwise lost. Fix available in SLF4J version 1.7.15.
> {quote}
> Analysis will need to be done to ensure this works as expected before the fork is no longer required.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months