Return-Path: X-Original-To: apmail-db-derby-dev-archive@www.apache.org Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id DB091772E for ; Fri, 9 Dec 2011 21:14:02 +0000 (UTC) Received: (qmail 41781 invoked by uid 500); 9 Dec 2011 21:14:02 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 41742 invoked by uid 500); 9 Dec 2011 21:14:02 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 41735 invoked by uid 99); 9 Dec 2011 21:14:02 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 09 Dec 2011 21:14:02 +0000 X-ASF-Spam-Status: No, hits=-2001.2 required=5.0 tests=ALL_TRUSTED,RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 09 Dec 2011 21:14:00 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id 53F9F10A9EC for ; Fri, 9 Dec 2011 21:13:39 +0000 (UTC) Date: Fri, 9 Dec 2011 21:13:39 +0000 (UTC) From: "Rick Hillegas (Commented) (JIRA)" To: derby-dev@db.apache.org Message-ID: <296660180.60178.1323465219345.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Commented] (DERBY-866) Derby User Management Enhancements MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13166566#comment-13166566 ] Rick Hillegas commented on DERBY-866: ------------------------------------- Hi Kathey, Thanks for reading the spec and for your comments. Just to recap some of the points I made in my previous response to Mike: o A separate credentials database is only necessary for systems which already manage multiple Derby databases. Presumably those systems are familiar with the problems of managing multiple Derby databases in a single JVM. o I do not understand your comment about plugability. This feature will slightly increase the size of Derby's engine jar and the size of an empty Derby database. However, I expect those increases to be well within the percentage growth which we have tolerated for feature releases over the last 6 years. Thanks, -Rick > 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, derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff, dummyCredentials.properties > > > 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