[
https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-866:
--------------------------------
Attachment: derby-866-22-aa-dboFirst.diff
Attaching derby-866-22-aa-dboFirst.diff. This patch addresses the edge case
described above on 2012-03-19. Now the DBO must be the first user whose
credentials are stored. Storing credentials for the DBO automatically marks the
database as a credentials DB. Committed at subversion revision 1302868.
Turning a legacy database into a credentials DB is now simpler. All you have to
do is call syscs_create_user() to store the DBO's credentials.
Regression tests passed cleanly for me. I also successfully ran
NativeAuthenticationServiceTest on OJEC.
Touches the following files:
----------
M
java/engine/org/apache/derby/impl/jdbc/authentication/NativeAuthenticationServiceImpl.java
M java/engine/org/apache/derby/catalog/SystemProcedures.java
Make sure that the first credentials which are stored are those of the DBO. If
they are, then set derby.authentication.provider=NATIVE::LOCAL in the database.
That last piece of logic was moved out of the NATIVE authentication service
into the syscs_create_user procedure.
----------
M java/engine/org/apache/derby/loc/messages.xml
M java/shared/org/apache/derby/shared/common/reference/SQLState.java
New error message raised if you try to store credentials for some other user
before you store the DBO's credentials.
----------
M
java/testing/org/apache/derbyTesting/functionTests/tests/lang/nast_init.sql
M java/testing/org/apache/derbyTesting/functionTests/tests/lang/nast1.jar
This is the script which creates the jar files used by
NativeAuthenticationServiceTest. The script was changed so that it no longer
explicitly sets derby.authentication.provider=NATIVE::LOCAL in the database
(not needed anymore). In addition, I turned off password expiration in the
jar'd databases so that NativeAuthenticationServiceTest won't fail 32 days
after checking in new jar'd databases.
----------
D
java/testing/org/apache/derbyTesting/functionTests/tests/lang/NativeAuthProcs.java
M
java/testing/org/apache/derbyTesting/functionTests/tests/lang/_Suite.java
NativeAuthProcs was failing to shutdown correctly because user creation now
turns on NATIVE+LOCAL authentication. This test is largely redundant--except
for the password hashing tests, all of its cases are also tested in
NativeAuthenticationServiceTest now. The password hashing tests were moved to
NativeAuthenticationServiceTest and NativeAuthProcs was deprecated.
----------
M
java/testing/org/apache/derbyTesting/functionTests/tests/lang/NativeAuthenticationServiceTest.java
This test needed lots of little tweaks to handle the new behavior.
----------
M
java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/Changes10_9.java
Now the upgrade tests have to be careful to not actually store the DBO's
credentials since that will turn on NATIVE+LOCAL authentication.
> Derby User Management Enhancements
> ----------------------------------
>
> Key: DERBY-866
> URL: https://issues.apache.org/jira/browse/DERBY-866
> Project: Derby
> Issue Type: Improvement
> Components: Services
> Affects Versions: 10.2.1.6
> Reporter: Francois Orsini
> Assignee: Rick Hillegas
> Attachments: Derby_User_Enhancement.html,
> Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java,
> UserManagement.html, UserManagement.html, UserManagement.html,
> UserManagement.html, UserManagement.html, UserManagement.html,
> derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff,
> derby-866-02-ag-createDropUser.diff,
> derby-866-03-aa-resetModifyPassword.diff,
> derby-866-03-ab-resetModifyPassword.diff, derby-866-04-aa-fixRolesTest.diff,
> derby-866-05-aa-grantRevoke.diff, derby-866-06-aa-upgradeFrom10.1.diff,
> derby-866-07-aa-removeSQLPassword.diff, derby-866-08-aa-passwordHasher.diff,
> derby-866-08-ab-passwordHasher.diff, derby-866-08-ad-passwordHasher.diff,
> derby-866-09-ad-nativeAuthenticationService.diff,
> derby-866-09-ae-nativeAuthenticationServiceWithTests.diff,
> derby-866-10-ac-propChanging.diff, derby-866-11-aa-upgradeTest.diff,
> derby-866-12-ac-passwordExpiration.diff,
> derby-866-13-ab-systemWideOperationTests.diff,
> derby-866-14-ac-badNativeSpec.diff,
> derby-866-15-ae-dbInJarFileOrOnClasspath.diff,
> derby-866-16-aa-credDBViaSubprotocol.diff,
> derby-866-17-aa-grantRevokeNative.diff,
> derby-866-18-aa-encryptedCredentialsDB.diff,
> derby-866-19-aa-replicationTest.diff, derby-866-20-aa-npeAndUserProbing.diff,
> derby-866-20-ab-npeAndUserProbing.diff,
> derby-866-21-aa-emptyCredentials.diff, derby-866-21-ab-emptyCredentials.diff,
> derby-866-22-aa-dboFirst.diff, dummyCredentials.properties, releaseNote.html
>
>
> Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec
> attached to the JIRA).
> Abstract:
> This feature aims at improving the way BUILT-IN users are managed in Derby by
> providing a more intuitive and familiar DDL interface. Currently (in
> 10.1.2.1), Built-In users can be defined at the system and/or database level.
> Users created at the system level can be defined via JVM or/and Derby system
> properties in the derby.properties file. Built-in users created at the
> database level are defined via a call to a Derby system procedure
> (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property.
> Defining a user at the system level is very convenient and practical during
> the development phase (EOD) of an application - However, the user's password
> is not encrypted and consequently appears in clear in the derby.properties
> file. Hence, for an application going into production, whether it is embedded
> or not, it is preferable to create users at the database level where the
> password is encrypted.
> There is no real ANSI SQL standard for managing users in SQL but by providing
> a more intuitive and known interface, it will ease Built-In User management
> at the database level as well as Derby's adoption.
--
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
