CODEWITHSUNDEEP
javapermissionsdesktop-applicationmodularity
Mahmoud Saleh
Mahmoud Saleh

Reputation: 33625

Set up permissions/features in desktop application?

i have a desktop application that consists of 10 features, and some clients asks only for 8 features or 7 features. i want to have a way to manage adding/removing the permissions/features for the client (only i can control that). so that i can hide/show feature based on a flag.

is that should be done through a property file that contains the name of the feature with boolean flag, or what ?

please give me some ideas, thanks.

Upvotes: 1

Views: 457

Answers (6)

Jerry Andrews
Jerry Andrews

Reputation: 847

From your other answers, it sounds to me like the following additional details have cropped up; please let me know if I have these wrong:

  1. You're delivering your application as a .jar file,
  2. Each customer gets their build directly from you, and there's a small number of customers,
  3. You configure a build specifically for each customer, and
  4. You don't want your customers to be able to modify their feature access.

In that scenario, I'd store the "active" feature list in a hashed property value stored in a .properties file bound into the .jar. I'll describe one way to do that below. You generate the properties file just before delivery, add the file to the jar:

jar -uf applicationJarFile.jar configuration.properties

then sign the .jar and deliver it. At runtime, your app can load the properties file, run the hash of each feature, compare with the properties you've stored, and determine which ones are off or on.

Your properties, which determine which features are enabled, might consist of a list like this:

feature1=enabled
feature2=disabled
feature3=disabled
feature4=enabled

Write yourself a utility which hashes the whole string "feature1=enabled" plus a salt value, e.g. "feature1=enabledaKn087*h5^jbAS5yt". (There's code for this built into java; see How can I generate an MD5 hash?, for example.) The result will be an opaque 16-byte number, which you can then store in another properties file to be included in your app: feature1=1865834.... The salt value should be broken into multiple shorter strings in your code so your customer can't just retrieve it and easily duplicate the process themselves.

In your app, at startup, you construct the string above using both the "enabled" and the "disabled" value, run the MD5 of both, and compare it with the stored hash. That'll tell you what features to enable.

I think a separate .jar or .properties is a bad idea; it clutters your delivery.

You can automate the whole process fairly easily, since you can generate the properties on the fly any time, and bind them into your app.

You can add other "baked in" properties which gives you a lot of flexibility in the final deliverable, including things like skinning for customer branding.

As others have pointed out, though: there's lots of ways to approach this, depending on the rest of the details of your product and your overall goals. This is one way to do it, given the assumptions above. AFAIK, there's no "canonical" way to do this sort of thing.

Upvotes: 2

Swapnil
Swapnil

Reputation: 897

You should consider using a License management api to do the same, which will give u both security and capability to change License pre/post installations.

It is not advisable to build adhoc licensing capabilty, take a look at License3j and TrueLicense, they are both free and can help you gain perspective or better fulfil your requirement

Upvotes: 2

Tassos Bassoukos
Tassos Bassoukos

Reputation: 16152

Modularize the application and deploy to each client only those parts that he wants/has access to. There's many ways to do it (the most complete but heavyweight being OSGi), but the specifics depend on your circumstances and requirements.

The quickest way to implement it might be to simply extract your extra functionality in separate JARs, and on deployment update the classpath appropriately.

Upvotes: 1

Stuart
Stuart

Reputation: 407

This is very open ended - it really depends on what you're trying to achieve, and what you mean by a feature.

One approach is to use a plugin based architecture. e.g. you have an interface

public interface Feature {}

and provide each of your ten features as implementors of this interface. Then have some method which runs at application start which looks for Feature subclasses on the classpath.

You can control which features a client has by including only the relevant features on the classpath, e.g. using maven.

Upvotes: 0

Thomas
Thomas

Reputation: 88747

You could try and encode that in a file. I assume each user has an own installation/version of the application, right? I further assume the application should not need to check some web resource. Thus you need to implement that in a file.

However, you should encrypt that file and put the salt and key somewhere in the code where they can't easily be decompiled. Additionally create a hash to check for modifications of the file. That hash could be based on the application's size or something else.

Please note that there's no 100% security and any hacker could still crack your application. But in that case this would need some form of criminal energy not commonly present in the business world.

Upvotes: 1

Byter
Byter

Reputation: 1132

It depends on the kind of application,kind of security you want and the number of people likely to use the application.

If the number of clients is not that big you can store their preference in some in memory data structure like a Map . Otherwise you can use file system or a DB depending upon the kind of security you want.

Upvotes: 0

Related Questions