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 <[email protected]>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 <[email protected]>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 <[email protected]>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
