db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Francois Orsini (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-1823) Derby Developer's Guide - Issues w/ User authentication and authorization extended examples section/paragraph
Date Tue, 23 Oct 2007 00:20:50 GMT

    [ 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.


Mime
View raw message