On Sat, Apr 21, 2012 at 1:50 AM, Rick Hillegas <rick.hille...@oracle.com> wrote: > 3) ...or something else?
Possibly something else. Specifically, the only thing that doesn't really "work" with the way we're doing it now is that if you provide valid credentials but can't access the database, the error Derby passes back to the user is along the lines of "invalid user ID or password. UserAuthenticator only has a boolean return value so it isn't possible to pass the reason for being rejected using solely a UserAuthenticator. Which is why I wondered if there was a second step where a UserAuthoriser would be asked whether a user has authorisation to a database. Then when that returns false, a different error code would presumably come back which indicated a lack of access rather than the login being wrong. It seems this sort of thing does exist at the database level but as far as I can tell this requires setting properties on the database. But in our case it's tricky to do that because we don't want to be subject to authentication when using the database directly, only when going via the network server. In many ways it's tragic that this sort of thing in Derby is done using system properties and not via service setters on NetworkServerControl (even though NetworkServerControl does have an API, it's not an API which looks like it was designed to be embedded.) TX
