Hi, As described in: 14.4.1.1 Programming interfaces for resource factory references of EJB Spec 1.1, JOnAS2.0 implements DataSourceFactory and ConnectionManager so that our bean instance can obtain the reference to DataSource through JNDI. Given the sign-on information for underlying database by the deployment descriptor, our beans can get JDBC connection just by 'getConnection()' without hard-coded user name and password. And this is what EJB Spec requires the Container. (See the italic-ed sentence of page 212) So, I think the current implementation fully complies with the spec. On the other hand, restricting the access to our database is the critical issue, especially for network programming. In addition to the fact that EJB is network oriented, EJB server may be used for multiple applications. For example, someone may start EJB-hosting service (something like web-hosting service) using JOnAS in the near future. This means the access privilege to the underlying database between bean instances is also important. The above is why I insist the implementation of DataSourceFactory and ConnectionManager. My desirable implementation is: 1: The ConnectionManager cannot be retrieved outside the JOnAS. The current implementation allows some hacker to know the username and password of our database. 2: ConnectionManager.getConnection() can be used only by the bean instance who has <res-auth>Container</res-auth> element in the deployment descriptor. 3: ConnectionManager.getConnection(String username,String password) can be used only by the bean instance who has <res-auth>Application</res-auth> element in the deployment descriptor. As for 1, the following code (outside our JOnAS) works given the JNDI name of our DataSource: Context con=new InitialContext(); Object ds_obj=con.lookup(name); DataSource ds=(DataSource)ds_obj; String usr=((ConnectionManager)ds).getUserName()); String pss=((ConnectionManager)ds).getPassword()); The 3 above also ensures that only such a bean instance is allowed to log into the db with the privilege different than bean instances of container authentication. Most db software allows us to define the users with the different access privileges, and I've seen the actual system which depends on such a feature. Although this is not the EJB Spec intends, there may be a case that we need to give some specific beans the higher privilege. And Pool.openConnection(String user,Transaction tx) within ConnectionManager does not examine the username of PoolItem. It returns the PoolItem regardless the username. As you notice, I've posted some of my implementation for DataSourceFactory and related classes. My new code is very different than those. DataSourceFactory always returns ConnectionManager unless it is called outside JOnAS. But ConnectionManager.getConnection() or ConnectionManager.getConnection(String username,String password) returns null in inappropriate case. I attached the source code to this mail. After extracted, you will find my modified source files under the directory of 'modified_src'. The code fragments between: //Start:Jun Inamori (For authentication of DataSource) //End:Jun Inamori (For authentication of DataSource) are related ones. Any comments are welcome. -- Happy Java programming! Jun Inamori OOP-Reserch E-mail: [EMAIL PROTECTED] URL: http://www.oop-reserch.com

jonas_patch.zip

S/MIME Cryptographic Signature

Reply via email to