Hi Sunitha, Thanks very much for preparing the table of possibilities; that makes things much clearer.
I applied your patch to the current trunk successfully, and spot-checked a few of the various possibilities, and all seemed to be as you described, so I am able to confirm that your patch works for me. I had two follow-on questions, though: 1) On the client side, I was slightly surprised that this didn't give me an error or a warning: ij> connect 'jdbc:derby://localhost:1527/testdb;create=true;securityMechanism=4;user=bryan;password=bryan'; Is it actually passing the password to the server? Or simply ignoring it on the client side? 2) I was slightly surprised by the behavior of the 'not-set' column of your table. It seems like, if the property is not set on the server, then the server accepts any valid connection, regardless of security mechanism. That is, if I don't set the property, then the following script establishes 2 connections to the database: ij> connect 'jdbc:derby://localhost:1527/testdb;create=true;securityMechanism=4;user=bryan'; ij> connect 'jdbc:derby://localhost:1527/testdb;create=true;securityMechanism=3;user=bryan;password=bryan'; But if I set the derby.drda.securityMechanism property to a valid value, then the script establishes only the connection where the security mechanism matches, and the other(s) fail. So it seems like the behavior of the server with your patch is: - if derby.drda.securityMechanism is set to a valid mechanism, then the Network Server accepts *only* connections which use that security mechanism. No other types of connections are accepted - the derby.drda.securityMechanism is not set at all, then the Network Server accepts any connection which uses a valid security mechanism. Is that in fact the behavior that you expected and intended? thanks, bryan
