On 15 Sep 2004, at 23:07, Dain Sundstrom wrote:
On Sep 15, 2004, at 2:14 PM, Ken Horn wrote:
On WLS, the datastore on the default drivers is serializable (it's bound to the clustered jndi, via a ClusterRemoteRef), and so an servlet / ejb / client app can grab the ds from jndi (this may be using JNDI Reference / Factory stuff). The ds can then create a direct db connection from the code to the db.
Ah your talking WLS. Does this only work when you use weblogic's drivers or does it work with any driver? I suppose we could do the same thing. Does WLS handle moving the driver classes to the client or does it assume you have all the classes you need on the client?
OK. Have tried it with a WLS datasource, backed by a Sybase driver. This seems (from ktrace output) to pull a sybase ds across the rmi (the client prog has no jdbc drivers) loader, all configured. So looks quite WLS specific.
However, I also bound a raw SybDataSource instance into jndi, and pulled it out from the client (this needed the syb driver jar to provide the object factory to convert the javax.naming.Reference to a SybDataSource. This worked, so I think any jndi may have this problem / feature.
Therefore, if I bind a datasource into jndi, and fail to protect it via some contorted config (what we've thought of so far, is facades calling runAs beans through local interfaces), any user that can authenticate, and can write a java client (or find one), can access the database direct.
Assuming it has the permissions.... or does WLS serialize the username and password?
Either of the methods above have the database logins already contained in the datasource... and by casting back to SybDS in the second method I can get the db password -- nice!
I was wondering if the same is possible in Geronimo...
So key questions are:
* are datasources by default serializable (does Geronimo use something like the wls remote ref or is the raw driver datastore used?)
Not currently, but if you want it start by adding a JIRA "New Feature" issue.
I think DS's should probably be Serializable to permit this when desired, though I think they should generally avoid the password being seen. (not sure how, other than going back via the server..). I'll think about this some more before raising an issue.
* can client apps access the server jndi tree?
Not yet. Currently an client can only see EJBs with Remote interfaces via JNDI.
Is that because only remote interfaces are bound into that JNDI impl/instance or some other deeper reason?
* if yes for the previous q, is there a way to bind an object that isn't remotely accessible?
N/A, but we may change the above so what do you suggest we do?
I think any of:
* a different jndi tree - perhaps a different context factory etc
* a fixed branch of the tree with is not exported / visible to out-of-process clients
* a naming convention
* WLS style local-only roles & run-as
Depending on the JNDI impl, any are ok -- the first is probably best, but most hassle for users, while the next two are easier to use, but may be hacky to implement nicely (and raises questions about being able to sandbox apps/areas to only see bits they want.. can of worms?).
The role based one seems more j2ee, but is a pain to configure since I think you need the facade stuff mentioned earlier.
-dain
Ken
