db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: Security in Derby
Date Wed, 21 Feb 2007 18:02:25 GMT
Andrew McIntyre wrote:
> On 2/21/07, Kim Haase <Camilla.Haase@sun.com> wrote:

>> 2) In a JDBC program, calling the
>> org.apache.derby.jdbc.ClientDataSource.setSecurityMechanism method
>>
>> 3) Specifying the connection URL property securityMechanism
> 
> Note that these two are for specifying the security mechanism for the
> connection client side.
> 
>> But with the last one it seems you have to use a numeric literal? This
>> seems unfortunate. I wonder if that is why it is not documented?
> 
> I'm not clear on the reason for the lack of documentation, but I agree
> it is unfortunate. I've opened DERBY-2361 for adding documentation for
> the connection URLs. See also DERBY-963 for changing the client to use
> text names instead of numbers to match (1) and (2).

To be precise, 2) and 3) are both setting the same client 
property/attribute using a numeric value. In the example shown for 2) a 
Java constant is used that represents a number. In the DataSource case 
the property is a int property, in the JDBC attribute case the value 
needs to be an integer, but the api means that the integer has to be 
passed as a string (use of a Properties object or a JDBC URL).

Alternate ways of setting 2) & 3) can show use of a numeric literal for 
2) and use of the Java constant for 3).

   2a) setting the database source property through a application server 
api would have to use 3 (e.g. xml configuration file, html form).

   2b) ds.setSecurityMechanism(3);

   3a) Setting the JDBC attribute in a Java program could use the 
constant, e.g. properties.setProperty("securityMechanism", 
Integer.toString(ClientDataSource.STRONG_PASSWORD_SUBSTITUTE_SECURITY));


Dan.




Mime
View raw message