June 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-4249) isUserInRole returns always false when jacc is enabled and the principal roles are empty

by Roland Räz (JIRA)

isUserInRole returns always false when jacc is enabled and the principal roles are empty ---------------------------------------------------------------------------------------- Key: JBAS-4249 URL: http://jira.jboss.com/jira/browse/JBAS-4249 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Web (Tomcat) service Affects Versions: JBossAS-4.0.5.GA Reporter: Roland Räz Assigned To: Remy Maucherat We are using our won jacc policy and login modules that don't add (cache) the roles in the principal. In this situation, the org.jboss.web.tomcat.security.JaccAuthorizationRealm hasRole method always returns false. The reason behind that is that the method hasRole setups a Principal array that does not contain the principal itself (only the roles are contained) when getPrincipalRoles return a not null Set. The getPrincipalRoles retuns for the above described setup not null. The following code fixes the issue: public boolean hasRole(Principal principal, String name) { ... Principal[] principals = {principal}; Set roles = getPrincipalRoles(principal); if( roles != null ) { principals = new Principal[roles.size() + 1]; principals[0]= principal; Iterator it = roles.iterator(); for (int i=1;it.hasNext();i++) { principals[i] =(Principal) it.next(); } } ... In my opinion it would be even cleaner to use only the Principal and do not using the principal roles as own identity when querying a jacc provider. JBoss could then still extract in it's own jacc provider the principal roles from the principal. In the current design there is a clash between the role and principal names. The better solution is used in the EJB 2.x code (org.jboss.ejb.enterpriseContext.isCallerInRoleCheckForJacc(); It looks like this for servlets: ... Principal[] principals = {principal}; ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-3768) Define initial persistent format of the profile repository

by Scott M Stark (JIRA)

Define initial persistent format of the profile repository ---------------------------------------------------------- Key: JBAS-3768 URL: http://jira.jboss.com/jira/browse/JBAS-3768 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Deployment services Reporter: Scott M Stark Assigned To: Scott M Stark Fix For: JBossAS-5.0.0.Beta We need to define the initial profile repository format with consideration of future migrations, jsr88, admin tools. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

6
11
0 / 0

[JBoss JIRA] Created: (JBAS-3417) SocketException during minimal tests

by Jaroslaw Kijanowski (JIRA)

SocketException during minimal tests ------------------------------------ Key: JBAS-3417 URL: http://jira.jboss.com/jira/browse/JBAS-3417 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.0.0.Beta Environment: win xp, fedora core 5 Reporter: Jaroslaw Kijanowski while running the first test of the testsuite (jboss-minimal-tests), get a java.net.SocketException. server.log: 2006-07-22 17:05:55,046 DEBUG [org.jboss.deployment.MainDeployer] End deployment start on package: jboss-service.xml 2006-07-22 17:05:55,046 DEBUG [org.jboss.deployment.MainDeployer] Deployed package: file:/D:/jboss3/jboss-head/build/output/jboss-5.0.0.Beta/server/minimal/conf/jboss-service.xml 2006-07-22 17:05:55,046 INFO [org.jboss.system.server.Server] JBoss (MX MicroKernel) [5.0.0.Beta (build: CVSTag=HEAD date=200607220701)] Started in 3s:359ms 2006-07-22 17:05:55,281 DEBUG [org.jboss.naming.NamingService] Error writing response to /127.0.0.1 java.net.SocketException: Software caused connection abort: socket write error at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1676) at java.io.ObjectOutputStream$BlockDataOutputStream.setBlockDataMode(ObjectOutputStream.java:1585) at java.io.ObjectOutputStream.writeNonProxyDesc(ObjectOutputStream.java:1167) at java.io.ObjectOutputStream.writeClassDesc(ObjectOutputStream.java:1121) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1278) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073) at java.io.ObjectOutputStream.writeFatalException(ObjectOutputStream.java:1392) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:294) at org.jnp.server.Main$BootstrapRequestHandler.run(Main.java:476) at org.jboss.util.threadpool.RunnableTaskWrapper.run(Unknown Source) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:743) at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

3
2
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1287) enabling prepare-statement-cache throws error during startup

by Prabhat Jha (JIRA)

enabling prepare-statement-cache throws error during startup ------------------------------------------------------------ Key: JBPORTAL-1287 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1287 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.6.Alpha2 Environment: QA: jboss running on cluster01, mysql5 running on cluster08, jdk1.4, jboss-portal.sar as of 2007 Feb, 21. Reporter: Prabhat Jha This happens on my end when prepared-statement-cache is on. Here is my portal-mysql5-ds.xml: <datasources> <local-tx-datasource> <jndi-name>PortalDS</jndi-name> <connection-url>jdbc:mysql://10.16.0.103:3306/portal?jdbcCompliantTruncation=false</connection-url> <driver-class>com.mysql.jdbc.Driver</driver-class> <user-name>portal</user-name> <password></password> <min-pool-size>20</min-pool-size> <max-pool-size>40</max-pool-size> <prepared-statement-cache-size>100</prepared-statement-cache-size> </local-tx-datasource> </datasources> Once I comment out the prepared-statement-cache-size, then it starts fine. Given that Julien has not been able to reproduced on his end, he probably needs to have access to this environment or I have to see if I can reproduce in his environment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-4022) EJB security-domain tag in jboss.xml for a domain defined in login-config.xml only works if java:/jaas/ prefix is absent, contrary to the documentation.

by Erica Kane (JIRA)

EJB security-domain tag in jboss.xml for a domain defined in login-config.xml only works if java:/jaas/ prefix is absent, contrary to the documentation. -------------------------------------------------------------------------------------------------------------------------------------------------------- Key: JBAS-4022 URL: http://jira.jboss.com/jira/browse/JBAS-4022 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-4.0.4.GA Environment: Clustered Reporter: Erica Kane I created a security domain in the the JBoss server login-config.xml: <application-policy name = "webappDomain"> <authentication> <login-module code = "org.jboss.security.auth.spi.DatabaseServerLoginModule" flag = "required"> <module-option name = "dsJndiName">java:jdbc/web</module-option> <module-option name = "principalsQuery">select password from Users where username=?</module-option> <module-option name = "rolesQuery">select Role, 'Roles' from Roles where username=?</module-option> <module-option name = "unauthenticatedIdentity">guest</module-option> </login-module> </authentication> </application-policy> In jboss-web.xml, I have <?xml version="1.0" encoding="UTF-8"?> <jboss-web> <security-domain flushOnSessionInvalidation="true">java:/jaas/webappDomain</security-domain> <context-root>/web</context-root> </jboss-web> and this works perfectly for securing web pages. However, if I put the following tag in jboss.xml: <security-domain>java:/jaas/webappDomain</security-domain> I find that protected EJBs default to using the "other" security domain, as shown by error messages complaining about the missing user.properties file and so on (I have left "other" on the default setting of UsersRolesLoginModule). What DOES work is to put: <security-domain>webappDomain</security-domain> in jboss.xml without the java:/jaas/ prefix. However, this does not match the documentation. See http://docs.jboss.org/jbossas/jboss4guide/r4/html/ch8.chapter.html example 8.8. Of course there the tag is set to java:/jaas/other, which for this bug would default to "other" anyway. I think it is terribly confusing to have jboss.xml and jboss-web.xml using different forms for the security-domain, but even if this is necessary for some reason it should be corrected in the documentation. Other people appear to have run into this as well: http://forum.java.sun.com/thread.jspa?threadID=773530 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-3942) twiddle.sh should read run.conf - and other small ehancements

by Paul Jenner (JIRA)

twiddle.sh should read run.conf - and other small ehancements ------------------------------------------------------------- Key: JBAS-3942 URL: http://jira.jboss.com/jira/browse/JBAS-3942 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Other Affects Versions: JBossAS-4.0.5.GA Reporter: Paul Jenner The twiddle.sh script should read environment variables from run.conf in the same way as the startup and shutdown scripts do - e.g. JAVA_HOME and JAVA. Additionally twiddle.sh should honous the JAVA environment variable instead of overwriting it with $JAVA_HOME/bin/java or "java". This makes it consistent with startup and shutdown which do honour JAVA. Finally the header should be changed from JBoss Shutdown script to JBoss twiddle script :-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

4
6
0 / 0

[JBoss JIRA] Created: (JGRP-501) JGroups demo hosted by jboss.org

by Bela Ban (JIRA)

JGroups demo hosted by jboss.org -------------------------------- Key: JGRP-501 URL: http://jira.jboss.com/jira/browse/JGRP-501 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assigned To: Vladimir Blagojevic Priority: Minor Fix For: 2.5 Goal: users can download a minimal JGroups installation (either via WebStart or as an applet) and explore JGroups. The configuration would probably include TUNNEL and there would be a GossipRouter instance running, e.g. on labs.jboss.org. We could provide access to chat & whiteboard (org.jgroups.demos.wb.Whiteboard) This would also be a good test case for the new revamped GossipRouter. Plus, once we have redundant GossipRouters, we can test client failover. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

2
6
0 / 0

[JBoss JIRA] Created: (JGRP-409) Channel bundling

by Bela Ban (JIRA)

Channel bundling ---------------- Key: JGRP-409 URL: http://jira.jboss.com/jira/browse/JGRP-409 Project: JGroups Issue Type: Feature Request Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.6 We can distributed traffic across multiple sockets in the transport. E.g. if we have eth0 and eth1, and both are 100Mbps *full duplex*, then we should be able to send 100Mbps on eth0 and 100Mbps on eth1 *simultaneously*. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 3 months

3
8
0 / 0

[JBoss JIRA] Created: (JBAS-4460) Jboss Password Encryption Security Flaw

by Scott Kesecki (JIRA)

Jboss Password Encryption Security Flaw --------------------------------------- Key: JBAS-4460 URL: http://jira.jboss.com/jira/browse/JBAS-4460 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Security Affects Versions: JBossAS-4.0.3 SP1 Reporter: Scott Kesecki Assigned To: Scott M Stark The Jboss salt to encrypt and decrypt passwords are stored in clear text in the jboss source that can be downloaded by everyone. Anyone that has a basic understanding of how java works can take the source tree get the class definition that has the password encryption and turn it into a a password decryption class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

2
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-941) merge issue when removing from OneToMany in detached state (layered architecture)

by Rico Apfelbeck (JIRA)

merge issue when removing from OneToMany in detached state (layered architecture) --------------------------------------------------------------------------------- Key: EJBTHREE-941 URL: http://jira.jboss.com/jira/browse/EJBTHREE-941 Project: EJB 3.0 Issue Type: Bug Affects Versions: AS 4.2.0 CR1 Environment: 13:37:59,625 INFO [ServerInfo] Java version: 1.5.0_09,Sun Microsystems Inc. 13:37:59,625 INFO [ServerInfo] Java VM: Java HotSpot(TM) Server VM 1.5.0_09-b01,Sun Microsystems Inc. 13:37:59,625 INFO [ServerInfo] OS-System: Windows XP 5.1,x86 Reporter: Rico Apfelbeck We work on a client-server environment with a webstart-client with an own JVM. Only the server has access to the JPA. POJOs are transfered from client to server and back. Our Issue occurs in the following workflow: - We get an Object A on the server from the Entitymanager and transfer it to the client. - This Object has a OneToMany-relation to some Objects B (fetchtype: EAGER, cascade: ALL). In B we have a reference to A. - On the client we remove in A some B from the Set, for example with clean() and transfer A back to the server. - We merge A on the server. - There is no exception thrown. The returned A from the merge-call does not contain any B, reloading A by Id results in a restored list containing the removed Bs. While added new Bs to A are stored correctly, removing them doesn't result in the deletion of the removed Bs from the database. Updating B in the List in A results in updated Bs when merging A. Only the removal causes problems. We assume that the problem comes from checking the now empty list against the database. Reloading A before merging in the server and manually compare the List of Bs, using EntityManager.remove() when neccesary. helps our case, but that's not the way it shoud be. :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

4
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2007