Here is a link to the patch's issue: https://issues.apache.org/jira/browse/GERONIMO-4848

On Fri, Sep 4, 2009 at 9:07 PM, Quintin Beukes <quintin@skywalk.co.za> wrote:
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 <quintin@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_jencks@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



--
Quintin Beukes