Hi Trejkaz,
I can reproduce your results if my UserAuthenticator throws a
SQLException whose SQLState is 08004, one of the SQLStates reserved for
use by Derby. If my UserAuthenticator throws a SQLException whose
SQLState is Z, a state not reserved by Derby, then the exception
traverses th
On Mon, Apr 23, 2012 at 10:50 PM, Rick Hillegas
wrote:
> UserAuthenticator.authenticateUser() can throw a SQLException which explains
> that the user doesn't have access to the given database. I find that
> SQLExceptions raised by the following code reach the application:
[snip]
I just gave this
On 4/20/12 4:41 PM, Trejkaz wrote:
On Sat, Apr 21, 2012 at 1:50 AM, Rick Hillegas 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 data
On Sat, Apr 21, 2012 at 1:50 AM, Rick Hillegas 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
Hi Trejkaz,
I do not see any responses to your email yet. I did not respond
immediately because I was not sure what help you wanted from the
community. Maybe other people were confused too.
It sounds as though you have written your own custom authenticator
backed by a database which maintain
Hi all.
We are using a custom UserAuthenticator to integrate Derby into our
own user database.
At the moment, this custom UserAuthenticator is also doing the job of
tracking who can open which database. So of course when we deny
someone because they don't have access, the error message they get i
