Over a million developers have joined DZone.

A Usable & Secure Mechanism for Plugins in the Lobo Browser

DZone's Guide to

A Usable & Secure Mechanism for Plugins in the Lobo Browser

· Java Zone ·
Free Resource

"I love writing authentication and authorization code." ~ No Developer Ever. Try Okta Instead.

One excellent side effect of Lobo's Java Web Browser being a pure Java application is the fact that it can acquire its infrastructure from a pure Java application framework. And, apparently, that's exactly what it needs, because Jose, its project lead, wrote the following at the end of my recent article How to Add Syntax Coloring for XML in the Lobo Java Web Browser: "I think an important next step in the project is to come up with a more usable and secure mechanism to install plugins." In this article, I look at how to achieve that and show preliminary results.

The Lobo Java web browser is perfectly positioned for migration to the NetBeans Platform. I can say this with confidence for the following reasons:

  • It needs an infrastructural basis. Clearly, from Jose's statement quoted above, the browser has developed to such an extent that the lack of certain common infrastructural paradigms is becoming a significant problem. The "usable and secure mechanism to install plugins" is the one most clearly felt, but points to other similar issues. For example, if you're missing a plugin mechanism, you could also be battling with other infrastructural concerns, such as a windowing system and a persistence methodology.

    Indeed, from studying the code, there seems to be a lot of code dealing with persistence. I believe the caching mechanism, which seems to be spread in a variety of places throughout the application, must be quite difficult to maintain. Similarly, the browser comes with a number of different types of windows and I wonder whether these are all necessary, in light of the various windowing systems that are currently available (e.g., JDoggy and so on). But, the NetBeans Platform provides all of the above at the same time, so seems appropriate since so many infrastructural concerns are applicable in this case.

  • It is pure Java. The ui toolkit used by this browser is Swing. That's wonderful because it means that the ui doesn't need to be rewritten, in order to be moved to the NetBeans Platform, which is also Swing-based. It "only" needs to be migrated. Not just that, but someone who understands the code behind this browser is going to find it relatively easy to transfer the relevant parts to the NetBeans Platform, since the ui toolkit is the same.
  • It is modular already. In yesterday's article I showed how to set up the browser as a normal Java application. In that context, this is how the project outline looks:

    Once it is moved to the NetBeans Platform, here's the project structure again. Note how similar it is (I only added the Substance look and feel, as a new module):

    The modular structure of the original application lends itself very well to the modular architecture of the NetBeans Platform. In fact, in most cases I simply copied and pasted the packages from the original modules into the new modules.

Now, this is how the official Lobo browser currently looks, i.e., when you download it from the Lobo site and run the JAR file:

And, though I haven't got the connection working correctly yet (hence the error message), and have disabled several parts of the application temporarily (such as the security manager and the caching mechanism), this is how it currently looks on the NetBeans Platform:

Above, I have selected the Plugins menu item. That's the usable and secure mechanism for installing plugins that I referred to earlier. (One distributes plugins by putting them on a server, describing them in an XML file that is also on a server, and then telling one's users to register that XML file in the Plugins Manager, which is accessed from the Plugins menu item above. Then the application accesses the server that provides the plugins, as described in the XML file.) However, the architecture of the Lobo plugins would need to be looked at in light of the structure of NetBeans modules. They are not the same and quite possibly the structure of Lobo plugins would need to be changed considerably to make them conform to the requirements of the NetBeans Platform. On the other hand, the application above can now, already, benefit from MANY plugins that have been made for the NetBeans Platform.

There is a lot left to be done. The above is a first step and I have already learned a lot from it. Hoping to get further with it, which would mainly involve getting the connection to work and then moving the menu item code into the menu items that you see above. But, most importantly, I need to look at how to restructure the Lobo plugins in such a way that they're NetBeans modules. The clientlets, for example, need to be installed as NetBeans modules rather than JARs in the distro's ext folder.

"I love writing authentication and authorization code." ~ No Developer Ever. Try Okta Instead.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}