Alternative Authentication Strategy

[Q Beukes]

Hey,

My module structure is basically something like this. I have a single module which contains some core classes/libraries used by all our modules. All our other modules depend on it.

Further, the other modules use a class in this module to do EJB lookups. This means the InitialContext has it's configuration in this core module. It happens via Spring. So in the core module I have a Spring configuration for the InitialContext, and the other modules have their own spring configuration files for the EJBs. Their Spring JNDI lookups depend on this one's.

Now, to have the InitialContext created successfully, you need to supply authentication credentials in the InitialContext configuration. 

My problem is in retrieving these credentials from the user.

At first I made a modal login dialog in the core module's Activator, in the restored() method. This worked fine. restored() will be called, the username/password retrieved, a JNDI lookup attempted which when successful would return, and an AuthenticationException raised if unsuccessful.

Though, I noticed when you close the application with open editor windows, these editor windows are restored automatically next time you open the application. This seems to happen before core's restored() method was called. Let me give some diagrams of the 2 scenarios.

In a clean/first launch scenario, this is a typical order of actions:

Core loaded -> Dependant modules loaded -> Core Installer.restored() invoked -> Username/password retrieved and authentication completed -> UI opens -> All Done

When I leave an open editor which does an EJB call to display it's data, the following happens at startup

Core loaded -> Dependant modules loaded -> Component restored -> JNDI context opened -> Authentication information unavailable -> Exception raised -> Component fails to load with an error

I would think that, since all modules depend on the core module it would first be completely restored before the other modules are restored?

My question is basically if there is an alternative way to have some authentication code load before all else? I changed my InitialContext to show the login dialog on request, but this causes a problem with failed/cancelled logins, as I can't find a way to cleanly shut down the platform in the middle of component restoration. This results in an EJB lookup failing, and to wrap ALL lookups throughout the application with checks for this seems overkill.

I also tried to put the authentication code inside the only other call in the Installer which gets call before restored(), though the ClassLoaders aren't setup here yet, so Spring fails to see the classes which handle the login.

A clean, definite way would be appreciated. I was thinking of doing it before the platform loads, and on success just start loading the platform's main() method, but I can't find a way to do this without having to package my application core libraries twice, once in the .nbm and once for the "loader". If there is a way to do this without having 2 copies of my core JARs, this could work as well.

I'm very lost at this point. Any advise would be appreciated.

Quintin Beukes

[Jesse Glick]

Quintin Beukes wrote:
> I would think that, since all modules depend on the core module it would
> first be completely restored before the other modules are restored?

Yes, ModuleInstall.restored implementations should be called in natural dependency order. If you can reproduce otherwise with a minimal self-contained test case please
file a bug report.

[Quintin Beukes-2]

ModuleInstall.restored is being called in order. That's not the problem. The problem is that the TopComponents that were left open are instantiated before the ModuleInstall.restored is called.

Quintin Beukes

On Thu, Oct 29, 2009 at 10:07 PM, Jesse Glick <jesse.glick@...> wrote:

Quintin Beukes wrote:

I would think that, since all modules depend on the core module it would first be completely restored before the other modules are restored?

Yes, ModuleInstall.restored implementations should be called in natural dependency order. If you can reproduce otherwise with a minimal self-contained test case please file a bug report.

[Jesse Glick]

Quintin Beukes wrote:
> The problem is that the TopComponents that were left open are
> instantiated before the ModuleInstall.restored is called.

There is no guarantee that other code will not be run before ModuleInstall.restored.

If you need to run some setup code before other things happen, rather than using ModuleInstall it is generally better to have some initialization API which is called on
demand. It can be a no-op if called more than once in a given session.