10個の機能で構成されるデスクトップアプリケーションがあり、一部のクライアントは8個の機能または7個の機能のみを要求します。クライアントのアクセス許可/機能の追加/削除を管理する方法が必要です(私だけがそれを制御できます)。フラグに基づいて機能を表示/非表示にできるようにします。
これは、ブールフラグが付いた機能の名前を含むプロパティファイルを介して実行する必要がありますか、それとも何ですか?
いくつかのアイデアをください、ありがとう。
10個の機能で構成されるデスクトップアプリケーションがあり、一部のクライアントは8個の機能または7個の機能のみを要求します。クライアントのアクセス許可/機能の追加/削除を管理する方法が必要です(私だけがそれを制御できます)。フラグに基づいて機能を表示/非表示にできるようにします。
これは、ブールフラグが付いた機能の名前を含むプロパティファイルを介して実行する必要がありますか、それとも何ですか?
いくつかのアイデアをください、ありがとう。
ライセンス管理APIを使用して同じことを行うことを検討する必要があります。これにより、セキュリティと、インストールの前後にライセンスを変更する機能の両方が提供されます。
アドホックライセンス機能を構築することはお勧めできません。License3jとTrueLicenseを見てください。どちらも無料であり、見通しを立てたり、要件をより適切に満たすのに役立ちます。
あなたの他の回答から、次の追加の詳細が切り取られたように私には聞こえます。これらが間違っている場合はお知らせください。
そのシナリオでは、「アクティブな」機能リストを、.jarにバインドされた.propertiesファイルに格納されているハッシュ化されたプロパティ値に格納します。そのための1つの方法を以下に説明します。配信の直前にプロパティファイルを生成し、ファイルをjarに追加します。
jar -uf applicationJarFile.jar configuration.properties
次に、.jarに署名して配信します。実行時に、アプリはプロパティファイルを読み込み、各機能のハッシュを実行し、保存したプロパティと比較して、どのプロパティがオフかオンかを判断できます。
有効にする機能を決定するプロパティは、次のようなリストで構成されている場合があります。
feature1=enabled
feature2=disabled
feature3=disabled
feature4=enabled
文字列全体「feature1=enabled」とソルト値をハッシュするユーティリティを自分で作成します(例:「feature1 = enabledaKn087 * h5 ^ jbAS5yt」)。(これにはJavaに組み込まれたコードがあります。たとえば、MD5ハッシュを生成するにはどうすればよいですか?を参照してください。)結果は不透明な16バイトの数値になり、アプリに含めるために別のプロパティファイルに保存できます。 feature1 = 1865834 ....ソルト値は、コード内で複数の短い文字列に分割する必要があります。これにより、顧客はそれを取得してプロセスを簡単に複製できなくなります。
アプリでは、起動時に、「enabled」と「disabled」の両方の値を使用して上記の文字列を作成し、両方のMD5を実行して、保存されているハッシュと比較します。有効にする機能がわかります。
別の.jarまたは.propertiesは悪い考えだと思います。それはあなたの配達を乱雑にします。
プロパティはいつでもその場で生成し、アプリにバインドできるため、プロセス全体をかなり簡単に自動化できます。
他の「焼き付け」プロパティを追加して、顧客のブランディングのためのスキニングなど、最終的な成果物に多くの柔軟性を与えることができます。
ただし、他の人が指摘しているように、製品の残りの詳細と全体的な目標に応じて、これにアプローチする方法はたくさんあります。上記の仮定を考えると、これはそれを行う1つの方法です。AFAIK、この種のことを行うための「標準的な」方法はありません。
それをファイルにエンコードしてみてください。各ユーザーが独自のアプリケーションのインストール/バージョンを持っていると思いますよね?さらに、アプリケーションがWebリソースをチェックする必要はないと思います。したがって、それをファイルに実装する必要があります。
ただし、そのファイルを暗号化し、ソルトとキーをコード内の簡単に逆コンパイルできない場所に配置する必要があります。さらに、ファイルの変更をチェックするためのハッシュを作成します。そのハッシュは、アプリケーションのサイズなどに基づいている可能性があります。
100%のセキュリティはなく、ハッカーがアプリケーションをクラックする可能性があることに注意してください。しかし、その場合、これには、ビジネスの世界では一般的に存在しない何らかの形の犯罪エネルギーが必要になります。
アプリケーションをモジュール化し、各クライアントに、アクセスしたい/アクセスできる部分のみをデプロイします。それを行うには多くの方法がありますが(最も完全ですが、最も重いのはOSGiです)、詳細は状況と要件によって異なります。
これを実装する最も簡単な方法は、追加の機能を別々のJARに抽出し、デプロイ時にクラスパスを適切に更新することです。
これは、アプリケーションの種類、必要なセキュリティの種類、およびアプリケーションを使用する可能性のあるユーザーの数によって異なります。
クライアントの数がそれほど多くない場合は、マップなどのメモリデータ構造にクライアントの設定を保存できます。それ以外の場合は、必要なセキュリティの種類に応じて、ファイルシステムまたはDBを使用できます。
これは非常にオープンエンドです-それはあなたが何を達成しようとしているのか、そしてあなたが機能によって何を意味するのかによって本当に異なります。
1つのアプローチは、プラグインベースのアーキテクチャを使用することです。例えばあなたはインターフェースを持っています
public interface Feature {}
そして、このインターフェースの実装者として、10の機能のそれぞれを提供します。Feature
次に、クラスパスでサブクラスを探すアプリケーションの起動時に実行されるメソッドをいくつか用意します。
Mavenを使用するなど、クラスパスに関連する機能のみを含めることで、クライアントが持つ機能を制御できます。