The reason I put it in the login module itself is because you get different
types of login modules, some not supporting the "retry concept", like
perhaps a login module that does host based authentication. Since the
OpenejbRemote login module does username/password configuration, and it is
in direct communication with the callback handler, I put the retry code in
there. This way it's also possible to reconfigure it with options.
I did the "cancel" detect by checking for a NPE. There might be a better way
to do this. Perhaps introduce a Cancelled class? Or maybe supply a
ConfirmationCallback to see if the user did attempt an authentication.
Though the latter might break existing code which fails if it receives an
unprovided for callback. So the NPE seemed like the safest fit for a patch.
If a legitimate NPE occurs though (because of a bug in the code or anything
where the user/password isn't set) then it will seem like the user cancelled
the Callback and the client will receive a "Cancelled by user" message.
What we can maybe do is just leave the handling of the NPE and let the
exception through as before? This way the log will show the exception (which
looks dirty) in legitimate cancels, but people would have a better idea of
what's happening in the cases where their code has bugs.
Let me know what your feelings are.
Q
On Fri, Sep 4, 2009 at 8:58 PM, Quintin Beukes <quin...@skywalk.co.za>wrote:
> Yeah, I actually made a modification of OpenejbRemoteLoginModule (if I
> recall the correct name).
>
> It basically introduces a new option FailedLoginTries. It has the following
> features introduced:
>
> 1. If not supplied it defaults to "1" (the current behaviour).
>
> 2. If an integer greater than 0, then it will try the specified amount of
> times before failing in the same way it did (with a FailedLoginException).
>
> 3. If you specify 0, it will try until you press cancel. In this case it
> will invoke the CallbackHandler with a TextOutputCallback containing an
> INFORMATION message "Login cancelled by user."
>
> 4. When a login fails it will first send a TextOutputCallback containing an
> ERROR message "Login failed for user: ${USER}", where USER is the username
> supplied to the previous NameCallback.
>
> I am in the process of creating the ticket for the patch submission, which
> is actually how I noticed your message (I came looking for my Apache JIRA
> username in my e-mail archive).
>
> Q
>
>
> On Fri, Sep 4, 2009 at 5:57 PM, David Jencks <david_jen...@yahoo.com>wrote:
>
>>
>> On Sep 4, 2009, at 6:06 AM, Quintin Beukes wrote:
>>
>> Hey,
>>>
>>> I created an application client, security realm and configured all this
>>> to run. Now, I get prompted for a password, but when entering it
>>> incorrectly, the application merely exits. The callback is called before my
>>> main() method is called, so I have no way to intercept this, but I would
>>> have thought that the application client container which invokes the
>>> callback would at least give an X amount of tries, or infinite tries until I
>>> raise some type of exception out of the CallbackHandler.
>>>
>>
>> I see your point :-)
>>
>>>
>>> Is there anyway to configure these things?
>>>
>>
>> Not yet, but this is great idea! Could you at least open a jira issue
>> asking for this functionality?
>> https://issues.apache.org/jira/browse/GERONIMO
>>
>> I suspect it wouldn't be too hard to implement.... if you would like to
>> take a look and possibly submit a patch I think the relevant code is in
>> plugins/client/geronimo-client, in the AppClientContainer class main method.
>>
>> thanks
>> david jencks
>>
>>
>>> --
>>> Quintin Beukes
>>>
>>
>>
>
>
> --
> Quintin Beukes
>
--
Quintin Beukes
