On 4/15/13 12:19 PM, Al Eridani wrote:
Thank you, Rick, I'll go on learning how to write a custom authenticator. Besides the section at pp. 105-107 of derbydev.pdf, are there any other resources that I could consult?
Hi Al,
That sounds like the right resource to consult. If you want your custom authenticator to store credentials in a local Derby database, you can use the NATIVE authentication support described in the Reference Guide sections on the SYSCS_UTIL.SYSCS_CREATE_USER, SYSCS_UTIL.SYSCS_DROP_USER, SYSCS_UTIL.SYSCS_MODIFY_PASSWORD, and SYSCS_UTIL.SYSCS_RESET_PASSWORD procedures.
Hope this helps, -Rick
On Mon, Apr 15, 2013 at 3:37 AM, Rick Hillegas <rick.hille...@oracle.com <mailto:rick.hille...@oracle.com>> wrote:On 4/12/13 3:49 PM, Al Eridani wrote: This may not be possible out-of-the-box, but here it goes, in case someone can help. We have an application that uses Derby with a single database and, until now, with no authentication. The application can be configured to start Derby with either the embedded or client data sources. The client data source is not needed by the application, but it is useful to remotely monitor the data. We would like to require authentication only for remote users, not the application. Alternatively, we could live with requiring authentication when the application boots Derby using the client data source, but not when using the embedded data source. The documentation does not address this. Does anybody have any ideas? Thanks! Al Hi Al, I don't know any way to do this purely within Derby's public API. However, you could write your own custom authenticator which checks to see whether the DRDAConnThread class appears on the stack returned by Thread.getStackTrace(). DRDAConnThread will only appear on the stack if you are authenticating a network connection request. Note that there are no guarantees that this will work in future revs of Derby; however, DRDAConnThread has been around for 7 years and no-one has suggested removing it. Hope this helps, -Rick
