You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Francois Orsini (JIRA)" <ji...@apache.org> on 2007/10/23 02:20:50 UTC

[jira] Commented: (DERBY-1823) Derby Developer's Guide - Issues w/ User authentication and authorization extended examples section/paragraph

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

Francois Orsini commented on DERBY-1823:
----------------------------------------

Great changes Kim. I tested all the samples and they worked great.

The only minor nit based on the write-ups is that you don't need the Derby jars to compile the samples. They are just required to run them. There's also a little step issue with the network client samples when it comes to shutting down the server at the end, which you should not have to do - if you do then we should tell the user to restart the server before running the samples.

So I would change: (for embedded)

"Before you compile and run AuthExampleEmbedded.java, make sure that %DERBY_HOME%\lib\derby.jar (or $DERBY_HOME/lib/derby.jar) is in your classpath."

into -->

"Compile AuthExampleEmbedded.java
Before you run this program, make sure that %DERBY_HOME%\lib\derby.jar (or $DERBY_HOME/lib/derby.jar) is in your classpath."

and (for client-server)

"Before you compile these programs, make sure that %DERBY_HOME%\lib\derbyclient.jar (or $DERBY_HOME/lib/derbyclient.jar) is in your classpath.

Before you run these programs, start Derby as described in "Activity 4: Create and run a JDBC program using the client driver and Network Server" in Getting Started with Derby. After you run the programs, stop Derby as described in the same topic."

into -->

"Compile AuthExampleClient1.java and AuthExampleClient2.java"
Before you run these programs, make sure that %DERBY_HOME%\lib\derbyclient.jar (or $DERBY_HOME/lib/derbyclient.jar) is in your classpath,
then start Derby server as described in "Activity 4, step 2: Create and run a JDBC program using the client driver and Network Server" in Getting Started with Derby guide."

Another comment which is probably best treating in a separate JIRA is that we should probably document the fact that users can now use GRANT/REVOKE instead of Derby's non-standard built-in authorization implementation, but I would do this in a separate JIRA and at least point them to the Grant/Revoke documentation / samples.
See derby.database.sqlAuthorization property which was added as part of DERBY-464.
We could add something along these lines:
"For more information about user authorization, see "User authorizations" in the Derby Developer's Guide"
http://db.apache.org/derby/docs/dev/devguide/devguide-single.html#cdevcsecure36595

> Derby Developer's Guide -  Issues w/ User authentication and authorization extended examples section/paragraph
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-1823
>                 URL: https://issues.apache.org/jira/browse/DERBY-1823
>             Project: Derby
>          Issue Type: Bug
>          Components: Documentation
>    Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.2.2.0, 10.3.1.4
>            Reporter: Francois Orsini
>            Assignee: Kim Haase
>            Priority: Minor
>         Attachments: DERBY-1823-2.diff, DERBY-1823.diff, DERBY-1823.zip
>
>
> There is a couple of issues with the paragraph/section  "User authentication and authorization extended examples" in the developer's guide
> http://db.apache.org/derby/docs/10.2/devguide/rdevcsecure26537.html
> 1) The methods turnOnBuiltInUsers() & turnOffBuiltInUsers() do NOT shutdown and reboot the database for which the 'derby.connection.requireAuthentication' authentication database property is being set - as this last one is a derby static property, it will not be taken into account until the database is rebooted (or the whole derby engine instance). Hence, the 2 checks for "Confirming requireAuthentication" is misleading as the property value is changed _but_ the actual database authentication enabling/disabling has not changed since it was last booted. Database needs to be shutdown and rebooted after 'derby.connection.requireAuthentication' is set and then some negative testing of invalid user connection needs to be added to show that only valid users can connect (in the case, authentication is being enabled).
> 2) Paragraph (extended examples section) also needs to be moved at the same level as the 2 above such as:
>   "User authentication example in a single-user, embedded environment"
>   http://db.apache.org/derby/docs/10.2/devguide/rdevcsecure125.html
>   "User authentication example in a client/server environment"
>   http://db.apache.org/derby/docs/10.2/devguide/rdevcsecure13713.html
> since the extended examples (once fixed - see 1)) can be applied in both a client-server and embedded environments context.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.