db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: double check on checkDataSource
Date Sun, 26 Feb 2006 01:19:08 GMT
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.


View raw message