X

Geertjan's Blog

  • April 8, 2014

Disable Module on Authentication Failure

Geertjan Wielenga
Product Manager

The user starts the application. The splash screen is shown. Right after the modules are loaded, as indicated by the text in the splash screen, a small login screen appears. The user fills in the wrong login credentials and clicks OK. The text in the splash screen shows that one or more modules are being turned off. Then the main window of the application appears. Because the login credentials were wrong, one or more of the modules have been disabled. 

import java.util.List;
import org.netbeans.api.autoupdate.OperationContainer;
import org.netbeans.api.autoupdate.OperationException;
import org.netbeans.api.autoupdate.OperationSupport;
import org.netbeans.api.autoupdate.UpdateElement;
import org.netbeans.api.autoupdate.UpdateManager;
import org.netbeans.api.autoupdate.UpdateUnit;
import org.openide.DialogDisplayer;
import org.openide.NotifyDescriptor;
import org.openide.modules.OnStart;
import org.openide.util.Exceptions;
@OnStart
public class Startable implements Runnable {
@Override
public void run() {
NotifyDescriptor.InputLine nd = new NotifyDescriptor.InputLine("Name", "Login");
//Got tired of typing it by hand:
nd.setInputText("admin");
Object response = DialogDisplayer.getDefault().notify(nd);
if (response == NotifyDescriptor.OK_OPTION) {
String username = nd.getInputText();
NotifyDescriptor.Message msg;
if (!username.equals("admin")) {
List<UpdateUnit> updateUnits =
UpdateManager.getDefault().getUpdateUnits(UpdateManager.TYPE.MODULE);
for (UpdateUnit updateUnit : updateUnits) {
//Get each module that is installed:
UpdateElement el = updateUnit.getInstalled();
//Of those that are installed, if it has the code name base
//of the module we are interested in, and it is enabled,
//continue with this procedure to disable it:
if (el != null
&& el.getCodeName().equals("com.mycompany.admin")
&& el.isEnabled()) {
try {
//Specify how we want to handle the module;
//here, we want to disable it:
OperationContainer oc = OperationContainer.createForDirectDisable();
oc.add(el);
//Finally, do the operation,
//passing a progress handle or, as in this case, null:
OperationSupport supp = (OperationSupport) oc.getSupport();
supp.doOperation(null);
} catch (OperationException ex) {
Exceptions.printStackTrace(ex);
}
}
}
}
}
}
}

Finally, the module is not shown in the Plugin Manager, so that it cannot be enabled from there. Only if the user logs in correctly is the module enabled.

Related reading:

Join the discussion

Comments ( 3 )
  • Peter Wednesday, April 9, 2014

    I understand where you are coming from but wouldn't the typical scenario be that the application should close itself if the user is not able to authenticate himself ?

    Disabling some modules on authentication failure assumes that the application has a "guest mode", i.e. that the application is useful even without authentication. If that's not the case there's no point in letting the user into the application only to show him an application that can't do anything.

    I don't have the "guest mode" (or anonymous user mode) in any of my apps. So what I learned here is how to dynamically disable modules which I can use for another case I've been working on.

    Excellent!

    Thanks.

    Peter


  • TORCHE Thursday, April 10, 2014

    I think one of the best scenarios is when an application must switch to another version, ex: some payed modules with license that has expired, the application uninstalls the modules without blocking the entire application (swith to free version).

    Excellent post.

    Djamel


  • guest Friday, April 11, 2014

    Very interesting approach, Geertjan!

    @Peter

    For example, a user can use accounts payable and invoicing but not general ledger or payroll modules.


Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.