[JBoss JIRA] (WFLY-3608) Expose configuring allowed file extensions
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-3608?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-3608:
-------------------------------
Fix Version/s: 9.0.0.Beta1
(was: 9.0.0.Alpha1)
> Expose configuring allowed file extensions
> ------------------------------------------
>
> Key: WFLY-3608
> URL: https://issues.jboss.org/browse/WFLY-3608
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final
> Environment: CentOs 5.5 & Ubuntu 10.04/12.04, Wildfly 8.1.0 Final, java version 1.7.0_60
> Reporter: Thomas Brenna
> Assignee: Tomaz Cerar
> Fix For: 9.0.0.Beta1
>
>
> It should be possible to modify allowed extensions without adding web.xml entry as we have it now.
> It should be an configuration option of servlet-container element. in undertow subsystem.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-3596) Running WF from build directory on Windows fails due to unresolved maven references
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-3596?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-3596:
-------------------------------
Fix Version/s: 9.0.0.Beta1
(was: 9.0.0.Alpha1)
> Running WF from build directory on Windows fails due to unresolved maven references
> -----------------------------------------------------------------------------------
>
> Key: WFLY-3596
> URL: https://issues.jboss.org/browse/WFLY-3596
> Project: WildFly
> Issue Type: Bug
> Components: Build System, Class Loading
> Affects Versions: 9.0.0.Alpha1
> Reporter: Nicklas Karlsson
> Assignee: Tomaz Cerar
> Priority: Minor
> Fix For: 9.0.0.Beta1
>
>
> Running WF from the build directory on a Windows host fails due to the clustering module.xml
> <resources>
> <artifact name="org.wildfly:wildfly-clustering-infinispan:9.0.0.Alpha1-SNAPSHOT"/>
> </resources>
> in the dist directory the section is correctly resolved as
> <resources>
> <resource-root path="wildfly-clustering-infinispan-9.0.0.Alpha1-SNAPSHOT.jar"/>
> </resources>
> and WF can be run from there
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-3619) XA END / un-enlist for database connection called before all persistence units have performed database updates
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-3619?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-3619:
-------------------------------
Fix Version/s: 9.0.0.Beta1
(was: 9.0.0.Alpha1)
> XA END / un-enlist for database connection called before all persistence units have performed database updates
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3619
> URL: https://issues.jboss.org/browse/WFLY-3619
> Project: WildFly
> Issue Type: Bug
> Components: EJB, JCA, JPA / Hibernate, Transactions
> Affects Versions: 8.0.0.Final
> Environment: Windows 7 64-bit
> JDK 1.8.0_05-b13 64-Bit
> MS SQL Server 2012 database
> Latest MS JDBC driver
> XA datasource
> Reporter: Andreas Liebscher
> Assignee: Scott Marlow
> Priority: Blocker
> Fix For: 8.2.0.CR1, 9.0.0.Beta1
>
> Attachments: persistence.xml, server-9.0.0.Alpha1-SNAPHOT-trace.log, server-9.0.0.Alpha1-SNAPHOT.log, server-all-traces-full.log.gz, server-org-jboss-as-jpa.log, server.jca.log, server_MSSQL_Trace.log
>
>
> While trying to port an EE application from JBoss5 to WF8 the following problem occurred:
> EJBs (@Required) using JPA to do some data changes.
> Some changes get already written to the database, others reside in the session cache.
> After the top EJB call returns, a Hibernate Session flush is triggered in beforeCompletion.
> Then more changes are flushed to the database, but I run in a reproduceable database locking problem.
> After some time an update of a row fails with lock wait timeout. This row has been inserted prior during the EJB call.
> There should be exactly one xa transaction active processing all data changes.
> But the database shows two active session, one is an xa transaction with sessionId -2 (orphaned), the other session is a local transaction.
> After analyzing all database communication with the help of the JDBC driver logging I found the following behaviour:
> - a connection is enlisted and xa start called
> - the same connection is used for several select / insert / update statements
> - after return of the top EJB call on the same connection xa end and connection un-enlist is called
> - the same connection is used for session flush (beforeCompletion) but with local transaction because the connection is no longer associated with the xa transaction, so locks can be expected.
> Shouldn't xa end be called AFTER beforeCompletion / session flush!?!
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-3659) wildfly 8 digest login-config throws javax.security.auth.callback.UnsupportedCallbackException
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-3659?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-3659:
-------------------------------
Fix Version/s: 9.0.0.Beta1
(was: 9.0.0.Alpha1)
> wildfly 8 digest login-config throws javax.security.auth.callback.UnsupportedCallbackException
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-3659
> URL: https://issues.jboss.org/browse/WFLY-3659
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Affects Versions: 8.1.0.Final
> Reporter: Joseph Hwang
> Assignee: Darran Lofthouse
> Fix For: 9.0.0.Beta1
>
>
> Password encryption in database login module with wildfly digest login config throws javax.security.auth.callback.UnsupportedCallbackException. These are sources.
> == web.xml
> <security-role>
> <role-name>administrator</role-name>
> </security-role>
> <login-config>
> <auth-method>DIGEST</auth-method>
> <realm-name>WildFly8DigestRealm</realm-name>
> </login-config>
> == jboss-web.xml
> <jboss-web>
> <security-domain>java:/jaas/my_secure_domain</security-domain>
> </jboss-web>
> == standalone.xml
> <security-domain name="my_secure_domain" cache-type="default">
> <authentication>
> <login-module code="Database" flag="required">
> <module-option name="dsJndiName" value="java:jboss/datasources/MySqlDS"/>
> <module-option name="principalsQuery" value="select password from credential where uid=?"/>
> <module-option name="rolesQuery" value="select urole, 'Roles' from credential where uid=?"/>
> <module-option name="hashAlgorithm" value="MD5"/>
> <module-option name="hashEncoding" value="RFC2617"/>
> <module-option name="hashUserPassword" value="false"/>
> <module-option name="hashStorePassword" value="true"/>
> <module-option name="passwordIsA1Hash" value="true"/>
> <module-option name="digestCallback" value="org.jboss.security.auth.callback.DigestCallbackHandler"/>
> <module-option name="storeDigestCallback" value="org.jboss.security.auth.callback.RFC2617Digest"/>
> </login-module>
> </authentication>
> </security-domain>
> Password is encrypted with below codes
> == EncryptPassword.java
> package com.aaa.encrypt;
> import org.jboss.crypto.CryptoUtil;
> public class EncryptPassword {
> public static void main(String[] args) {
> // TODO Auto-generated method stub
> String userName="admin";
> String realmName="WildFly8DigestRealm";
> String password="passwd123";
> String clearTextPassword=userName+":"+realmName+":"+password;
> String hashedPassword=CryptoUtil.createPasswordHash("MD5", "RFC2617", null, null, clearTextPassword);
> System.out.println("clearTextPassword: "+clearTextPassword);
> System.out.println("hashedPassword: "+hashedPassword);
> }
> }
> But login failed! The log shows the folowing exceptions :
> 2014-07-18 21:37:45,246 TRACE [org.jboss.security] (default task-3) PBOX000236: Begin initialize method
> 2014-07-18 21:37:45,246 DEBUG [org.jboss.security] (default task-3) PBOX000281: Password hashing activated, algorithm: MD5, encoding: RFC2617, charset: null, callback: org.jboss.security.auth.callback.DigestCallbackHandler, storeCallBack: org.jboss.security.auth.callback.RFC2617Digest
> 2014-07-18 21:37:45,247 TRACE [org.jboss.security] (default task-3) PBOX000262: Module options [dsJndiName: java:jboss/datasources/MySqlDS, principalsQuery: select password from credential where uid=?, rolesQuery: select urole, 'Roles' from credential where uid=?, suspendResume: true]
> 2014-07-18 21:37:45,247 TRACE [org.jboss.security] (default task-3) PBOX000240: Begin login method
> 2014-07-18 21:37:45,249 TRACE [org.jboss.security] (default task-3) PBOX000263: Executing query select password from credential where uid=? with username admin
> 2014-07-18 21:37:45,251 TRACE [org.jboss.security] (default task-3) PBOX000284: Created DigestCallback org.jboss.security.auth.callback.RFC2617Digest
> 2014-07-18 21:37:45,252 TRACE [org.jboss.security] (default task-3) PBOX000244: Begin abort method
> 2014-07-18 21:37:45,252 DEBUG [org.jboss.security] (default task-3) PBOX000206: Login failure: javax.security.auth.login.LoginException: PBOX000055: Failed to invoke CallbackHandler
> at org.jboss.security.auth.spi.UsernamePasswordLoginModule.createPasswordHash(UsernamePasswordLoginModule.java:444) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
> at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:280) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_60]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_60]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_60]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:762) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:690) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:688) [rt.jar:1.7.0_60]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:687) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext.login(LoginContext.java:595) [rt.jar:1.7.0_60]
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:408) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:333) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146) [picketbox-infinispan-4.0.21.Beta1.jar:4.0.21.Beta1]
> at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(JAASIdentityManagerImpl.java:111)
> at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verify(JAASIdentityManagerImpl.java:77)
> at io.undertow.security.impl.DigestAuthenticationMechanism.handleDigestHeader(DigestAuthenticationMechanism.java:265) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.DigestAuthenticationMechanism.authenticate(DigestAuthenticationMechanism.java:149) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:27) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_60]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_60]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_60]
> Caused by: javax.security.auth.callback.UnsupportedCallbackException
> at org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
> at org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
> at javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:947) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext$SecureCallbackHandler$1.run(LoginContext.java:944) [rt.jar:1.7.0_60]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_60]
> at javax.security.auth.login.LoginContext$SecureCallbackHandler.handle(LoginContext.java:943) [rt.jar:1.7.0_60]
> at org.jboss.security.auth.spi.UsernamePasswordLoginModule.createPasswordHash(UsernamePasswordLoginModule.java:434) [picketbox-4.0.21.Beta1.jar:4.0.21.Beta1]
> ... 49 more
> This cofiguration worked well in JBoss AS 7.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-3663) WildFly should manage JGroups and Infinispan thread pools by default
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-3663?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-3663:
-------------------------------
Fix Version/s: 9.0.0.Beta1
(was: 9.0.0.Alpha1)
> WildFly should manage JGroups and Infinispan thread pools by default
> --------------------------------------------------------------------
>
> Key: WFLY-3663
> URL: https://issues.jboss.org/browse/WFLY-3663
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.1.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 9.0.0.Beta1
>
>
> In our default configuration, both JGroups and Infinispan manage their own thread pools. Unfortunately, both projects do not handle thread pool lifecycle so well. Both projects use ExecutorService.shutdownNow() to end their thread pool lifecycles. This means that a channel or cache can stop, but still leave active threads running (albeit interrupted). We should have services that manage the lifecycle of our thread pools which ensure that all threads have terminated during Service.stop().
> This causes occasional OOMs in the Windows CI testsuite runs, due to too many threads lying around.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years
[JBoss JIRA] (WFLY-3710) Break close association of AppclientXml with WildFly-Core
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-3710?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-3710:
-------------------------------
Fix Version/s: 9.0.0.Beta1
(was: 9.0.0.Alpha1)
> Break close association of AppclientXml with WildFly-Core
> ---------------------------------------------------------
>
> Key: WFLY-3710
> URL: https://issues.jboss.org/browse/WFLY-3710
> Project: WildFly
> Issue Type: Task
> Components: Application Client, Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 9.0.0.Beta1
>
>
> AppClientXml is written on the basis that it is in the same project as the remaining domain management parsers, as an example it is dependent on calling certain version specific vault methods.
> Changes will also be needed to wildfly-core but any access to parsers in wildfly-core should be switched to agreed entry points that will be maintained by compatibility.
> As an example this block: -
> {code}
> if (element == Element.VAULT) {
> switch (namespace) {
> //Less than 1.1 does not end up in this method
> case DOMAIN_1_1:
> case DOMAIN_1_2:
> case DOMAIN_1_3:
> case DOMAIN_1_4:
> case DOMAIN_1_5:
> case DOMAIN_2_0:
> case DOMAIN_2_1: {
> parseVault_1_1(reader, address, namespace, list);
> break;
> }
> default: {
> parseVault_3_0(reader, address, namespace, list);
> }
> }
> {code}
> Should be replaced with a call to parseVault(), the parseVault() method will then be responsible for identifying the correct version.
> Changes should also be made to AppClientXml to make it compatible with multiple major versions in use concurrently for jboss-as-config - otherwise this class is seriously likely to be missed again for all further updates.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years