Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Mon, 21 Nov 2011 21:30:55 +0000 (UTC)
From: "Myrna van Lunteren (Commented) (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: 
 <2109570923.53286.1321911055483.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1136491220.44931.1321649931716.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (DERBY-5507) Orderly shutdown fails if you are
 using BUILTIN authentication and turn on derby.database.propertiesOnly
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-5507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13154554#comment-13154554 ] 

Myrna van Lunteren commented on DERBY-5507:
-------------------------------------------

Unfortunately, the original Cloudscape repository comments do not reference bug trackers for this change.

I did follow this code snippet (minus the 'derby' clause, of course) through the creation of the PropertyValidation class from code in the PropertyConglomerate class to its first inclusion on Aug 27, 1999, by djd, but the only comment on the check-in is: "Lock manager properties" (cloudscape revision 11958, for reference).

Before that, ValidateAndApplyMap looked like this:

	private Serializable validateApplyAndMap(TransactionController tc,
											 String key, Serializable value)
		 throws StandardException
	{
		Dictionary d = new Hashtable();
		getProperties(tc,d,false/*!stringsOnly*/,false/*!defaultsOnly*/);
		Serializable mappedValue = null;
 		if (notifyOnSet != null) {
			synchronized (this) {

				for (int i = 0; i < notifyOnSet.size() ; i++) {
					PropertySetCallback psc = (PropertySetCallback) notifyOnSet.elementAt(i);
					if (!psc.validate(key, value, d))
						continue;

					Serviceable s;
					if ((s = psc.apply(key,value,d)) != null)
						((TransactionManager) tc).addPostCommitWork(s);
					if (mappedValue == null)
 						mappedValue = psc.map(key, value, d);
				}
			}
		}

		//
		// RESOLVE: log device cannot be changed on the fly right now
		if (key.equals(Attribute.LOG_DEVICE))
			throw RawStoreStatementException.cannotChangeLogDevice();

		if (mappedValue == null)
			return value;
		else
			return mappedValue;
	}


At the time of this change, the method AddPropertySetNotification was also considerably changed, it had code added that also mentioned those SET_IN_* values/comments; 
                // set up the initial values by calling the validate and apply methods.
		// the map methods are not called as they will have been called
		// at runtime when the user set the property.
                [...more code added...]
				if (!who.validate(key, value, d))
					continue;

				// SET_IN_JVM - need to get value
				// SET_IN_DATABASE - use the stored value
				// SET_IN_APPLICATION - need to get value
				// NOT_SET - can't happen cos it does exist in d

				if (!dbOnly) {
					int whereSet = PropertyUtil.whereSet(key, d);
					if (whereSet != PropertyUtil.SET_IN_DATABASE)
						value = PropertyUtil.getSystemProperty(key);
				}
                   [...]
but that code was subsequently removed again (in cloudscape revision 12007, on Aug 30, 1999, by djd) with check-in comment:
"Fix bug with missing read lock configuration parameters."

At that time, (in addition to adding of a locks.waitTimeout property), it looks like an init method was added to PropertySetCallback, to SinglePool, some dummy init methods were added to some other classes, and PropertyUtil got a new method with signature:
public static String getPropertyFromSet(boolean dbOnly, Dictionary set, String key) 

Perhaps the code snippet in the method doValidateAndApplyMap should also have been removed at that time?

                
> Orderly shutdown fails if you are using BUILTIN authentication and turn on derby.database.propertiesOnly
> --------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-5507
>                 URL: https://issues.apache.org/jira/browse/DERBY-5507
>             Project: Derby
>          Issue Type: Bug
>          Components: Miscellaneous
>    Affects Versions: 10.9.0.0
>            Reporter: Rick Hillegas
>
> The following script raises an assertion on the last line. We are failing during the encryption of the password. The assertion prints out the plaintext of the password. I ran the script with the following command line:
> java \
>   -Dderby.connection.requireAuthentication=true  \
>   -Dderby.authentication.provider=BUILTIN \
>   -Dderby.user.test_dbo=test_dbopassword \
>   org.apache.derby.tools.ij $SCRIPT
> Here is the script:
> connect 'jdbc:derby:memory:db;create=true;user=test_dbo;password=test_dbopassword';
> call syscs_util.syscs_set_database_property( 'derby.connection.requireAuthentication', 'true' );
> call syscs_util.syscs_set_database_property( 'derby.authentication.provider', 'BUILTIN' );
> -- shutdown works correctly if you comment out the following two lines
> call syscs_util.syscs_set_database_property( 'derby.user.test_dbo', 'test_dbopassword' );
> call syscs_util.syscs_set_database_property( 'derby.database.propertiesOnly', 'true' );
> -- fails to authenticate correct credentials
> connect 'jdbc:derby:memory:db;shutdown=true;user=test_dbo;password=test_dbopassword';
> Here is the assertion printed on the screen:
> ERROR XJ001: Java exception: 'ASSERT FAILED Unknown authentication scheme for token test_dbopassword: org.apache.derby.shared.common.sanity.AssertFailure'.
> Here is the stack trace in derby.log:
> org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED Unknown authentication scheme for token test_dbopassword
> 	at org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:162)
> 	at org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:147)
> 	at org.apache.derby.impl.jdbc.authentication.BasicAuthenticationServiceImpl.encryptPasswordUsingStoredAlgorithm(BasicAuthenticationServiceImpl.java:282)
> 	at org.apache.derby.impl.jdbc.authentication.BasicAuthenticationServiceImpl.authenticateUser(BasicAuthenticationServiceImpl.java:199)
> 	at org.apache.derby.impl.jdbc.authentication.AuthenticationServiceBase.authenticate(AuthenticationServiceBase.java:279)
> 	at org.apache.derby.impl.jdbc.EmbedConnection.checkUserCredentials(EmbedConnection.java:1220)
> 	at org.apache.derby.impl.jdbc.EmbedConnection.<init>(EmbedConnection.java:422)
> 	at org.apache.derby.impl.jdbc.EmbedConnection30.<init>(EmbedConnection30.java:73)
> 	at org.apache.derby.impl.jdbc.EmbedConnection40.<init>(EmbedConnection40.java:51)
> 	at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Driver40.java:70)
> 	at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:255)
> 	at org.apache.derby.jdbc.AutoloadedDriver.connect(AutoloadedDriver.java:143)
> 	at java.sql.DriverManager.getConnection(DriverManager.java:582)
> 	at java.sql.DriverManager.getConnection(DriverManager.java:154)
> 	at org.apache.derby.impl.tools.ij.ij.dynamicConnection(ij.java:1528)
> 	at org.apache.derby.impl.tools.ij.ij.ConnectStatement(ij.java:1358)
> 	at org.apache.derby.impl.tools.ij.ij.ijStatement(ij.java:1143)
> 	at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:347)
> 	at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:245)
> 	at org.apache.derby.impl.tools.ij.Main.go(Main.java:229)
> 	at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:184)
> 	at org.apache.derby.impl.tools.ij.Main.main(Main.java:75)
> 	at org.apache.derby.tools.ij.main(ij.java:59)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira