Kathey Marsden wrote: > Looking at the method testDSRequestAuthentication() in checkDataSource, > the tests there end up to be mostly negative tests, failing with > database '' not found, but it would seem that that was not really the > intention e.g. here is some of the output. > > > ConnectionPoolDataSource - connectionAttributes=databaseName=wombat > getPooledConnection() - XJ004:Database '' not found. > getPooledConnection(null, null) - XJ004:Database '' not found. > getPooledConnection(fred, null) - XJ004:Database '' not found. > getPooledConnection(fred, wilma) - XJ004:Database '' not found. > getPooledConnection(null, wilma) - XJ004:Database '' not found. > getPooledConnection(null, databaseName=wombat) - XJ004:Database '' not > found. > getPooledConnection(fred, databaseName=wombat) - XJ004:Database '' not > found. > getPooledConnection(fred, databaseName=wombat;password=wilma) - > XJ004:Database '' not found. > getPooledConnection(fred, databaseName=wombat;password=betty) - > XJ004:Database '' not found. > > It looks like it was that way all the way back to contribution: > http://svn.apache.org/viewcvs.cgi/incubator/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/master/checkDataSource.out?rev=124918&view=markup > > I had been working to get the existing tests running as is with client > but now think I should probably fix the embedded version first to > actually access the database. Is that the right thing to do?
No. Mea culpa for not adding comments. If someone has configured a DataSource to access database A then that's all they expect the DataSource to provide access to. If a user request through the DataSource also allows acces to database B, then that would be a security hole. One potential hole in Derby is allowing the connection request (through the DataSource) to set the databaseName JDBC attribute property to B. This test ensures that any setting of connectionAttributes cannot override the database name specified by the data source. Other tests in this area relate to the Derby DataSource property, attributesAsPassword, which does allow JDBC attributes to be encoded as part of the password from a connection request. This was at the request of a Cloudscape customer before it was open sourced. Eventually the customer decided this was not the correct way to handle what they wanted, which was the ability to define a single data source that could access multiple databases. I think the customer took the better approach of writing their own DataSource that performed what they required, probably creating multiple Cloudscape DataSources, one per database. It would have been good to remove this property before Cloudscape when open source, as I don't think it's a good approach, and doesn't match the expected paradigm. Still I forgot, so it's part of the api, though one that should be deprecated. I'll add comments to those test cases. Dan.
