[JBoss JIRA] Created: (JBAS-8534) Security Credential is shared between threads
by Rajesh Bhabu (JIRA)
Security Credential is shared between threads
---------------------------------------------
Key: JBAS-8534
URL: https://jira.jboss.org/browse/JBAS-8534
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Security
Affects Versions: JBossAS-4.2.3.GA
Environment: JBOSS AS 4.2.3 on Linux
Reporter: Rajesh Bhabu
Assignee: Anil Saldhana
Because of the Anonymous issue as reported in https://jira.jboss.org/browse/JBAS-3945, we did coding something similar as following to workaround the issue. This was suggested by the JBOSS support team.
---------------------------------------------------------------------------------------------
When we are changing the principal (performing another login) we need to call
these Jboss APIs in our login module:
SecurityAssociation.popRunAsRole()
SecurityAssociation.pushRunAsRole()
This will pop the old run-as role and push the new run as role (which we want
the second transaction to run as).
Change the JAAS login module to explicitly set the new principal and
credentials during login. This was after the callback handler handle method
was invoked and we had the principal and credentials:
SecurityAssociation.setPrincipal(new SimplePrincipal(username));
SecurityAssociation.setCredential(password);
--------------------------------------------------------------------------------------------------------------------------
After doing this, we started seeing priniciple is shared amoung the threads. For example, user 1 logs in and see's information about user 2. This happens only after heavy load testing. This is also reproducible after couple of hours of running load test.
If we remove the above code, then the issue goes away. But anonymous issue appears.
Any Help is appreciated in helping finding the root cause of the issue.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[JBoss JIRA] Created: (JBAS-8106) Move MC/Weld deployer into AS
by Kabir Khan (JIRA)
Move MC/Weld deployer into AS
-----------------------------
Key: JBAS-8106
URL: https://jira.jboss.org/browse/JBAS-8106
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Deployers
Reporter: Kabir Khan
Assignee: Kabir Khan
Fix For: 6.0.0.M4
Since the rest of weld-int (JBAS-7938) now lives in AS, this lives here too now.
Until this feature is final, all jars are in weld.deployer, but it is disabled. To enable, uncomment this part of weld-deployers-jboss-beans.xml
<!-- UNCOMMENT THIS TO ENABLE WELD/MC INJECTION - This feature is currently very experimental and so not enabled by default -->
<!-- Adds plugin to BeanMetaDataDeployer that installs WeldKernelControllerContexts -->
<!-- bean name="WeldBeanMetaDataDeployerPlugin" class="org.jboss.weld.integration.deployer.mc.WeldBeanMetaDataDeployerPlugin"/ -->
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[JBoss JIRA] Created: (JBAS-8162) Failed to encode/decode password with name "pinaki" using SecureIdentityLoginModule
by Ravi Sankar (JIRA)
Failed to encode/decode password with name "pinaki" using SecureIdentityLoginModule
-----------------------------------------------------------------------------------
Key: JBAS-8162
URL: https://jira.jboss.org/browse/JBAS-8162
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JCA service
Affects Versions: JBossAS-4.2.3.GA
Environment: Any Operating system
Reporter: Ravi Sankar
Assignee: Jesper Pedersen
When trying to ecode/decode a password with characters "pinaki" using "SecureIdentityLoginModule" from JBOSS-JCA.JAR, i am getting the following excpetion.
One of our customers are using this as a password.
Password After encrption: "-4fb8f7c76b11ab"
Exception in thread "main" javax.crypto.IllegalBlockSizeException: Input length must be multiple of 8 when decrypting with padded cipher
at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..)
at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..)
at com.sun.crypto.provider.BlowfishCipher.engineDoFinal(DashoA13*..)
at javax.crypto.Cipher.doFinal(DashoA13*..)
at SecureIdentityLoginModule.decode(SecureIdentityLoginModule.java:39)
at SecureIdentityLoginModule.main(SecureIdentityLoginModule.java:48)
Please help me to get this issue resolved. Customer is behind me.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[JBoss JIRA] Created: (JBAS-8368) HAPartition MBean reports wrong JGroupsVersion
by martin walla (JIRA)
HAPartition MBean reports wrong JGroupsVersion
----------------------------------------------
Key: JBAS-8368
URL: https://jira.jboss.org/browse/JBAS-8368
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossAS-5.1.0.GA
Environment: JBossAS 5.1.0.GA, JAVA 1.6.0_17, Sun Solaris
Reporter: martin walla
On JMX Console the MBean jboss:service=HAPartition,Partition=.... has an attribute JGroupsVersion.
This displays 2.6.10.GA( $Id: Version.java,v 1.59.2.18 2009/04/28 14:25:33 vlada Exp $)
I have updated the JGroups version by removing the jgroups.jar and adding the jgroups-2.6.15.GA.jar.
After the startup the HAPartition MBean still reports 2.6.10.GA
IMHO the problem is that the class org.jboss.ha.framework.server.ClusterPartition uses the class org.jgroups.Version to get the attributes "description" and the "cvs" info in the method getJGroupsVersion().
But the strings in the class org.jgroups.Version are static final and therefore the value is added to the bytecode of the class org.jboss.ha.framework.server.ClusterPartition at compile time. A change of the jgoups version didn't change that.
So org.jboss.ha.framework.server.ClusterPartition reports the JGroupsVersion against it was compiled and that which it is available.
A use of the Method org.jgroups.Version.printDescription() instead should fix the problem IMHO.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[JBoss JIRA] Created: (JBAS-8729) Upgrade HSQLDB to 2.0
by Ondrej Medek (JIRA)
Upgrade HSQLDB to 2.0
---------------------
Key: JBAS-8729
URL: https://issues.jboss.org/browse/JBAS-8729
Project: JBoss Application Server
Issue Type: Thirdparty Change
Security Level: Public (Everyone can see)
Affects Versions: 6.0.0.CR1
Reporter: Ondrej Medek
Fix For: 6.0.0.Final
Please, upgrade HSQLDB to 2.0.0 (or better 2.0.1) in JBoss 6. HSQLDB 2.0.0 has greatly improved the compatibility with Oracle and other DBMS, so it is much more usable for unit testing and development. There should be not problem in upgrading. Just JBAS-8330
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years