特定の人々と共有したいプログラムを開発していますが、これらの人々について気が変わった場合は、プログラムへのアクセスを「取り消す」ことができるようにしたいと考えています。
これは、プログラムのすべてのインスタンスを単にブロックするのではなく、ユーザーごとに行うのが理想的です。ユーザーアカウントの行に沿ったものですが、現時点では、これらのアカウントを認証できるサーバーに実際にアクセスできないため、おそらくより簡単な方法が適切です.
私は野心的すぎますか？
(関連する場合は、Java を使用しています。)
申し訳ありませんが、いくつかの関連する詳細を見逃していました:
アプリケーションは、ほぼ完全にオンラインで使用されます。ユーザーベースが100をはるかに超えるとは思わない（そしてそれは野心的です）.100を超えるユーザーがいた場合、何らかの認証サーバーに飛び散るでしょうが、現時点でこれに最も近いのはファイルを保存できる基本的な FTP サーバー。
すべての回答に感謝します。SO がベストアンサーを 1 つしか選択できないのは残念です。：） 君たちありがとう。
100％の保証でこれを行う方法はありません。ハードウェアソリューション（回避することもできます）を除いて、ソフトウェアは操作可能です。
非常に簡単な例として、日付をチェックして実行できるかどうかを確認するWindowsプログラム（Javaの方がさらに簡単です）を取り上げます（トライアルウェアを考えてみてください）。時計を元に戻さなくても、それを打ち負かすことができます-日付を確認するためにどのような呼び出しを行っているかを把握し、その呼び出しを変更して常に機能する日付を返す代替DLLを提供します。
クライアントが接続する必要のあるサーバーを使用する場合は、サーバー側ですべての有効性チェックを実行できるため、より適切に機能します。ただし、ネットワークレベルで変更して、falseをtrueに変更できるため、単純にtrue/falseを返すことはできません。これを回避するには、SSLを使用してネットワークトラフィックを暗号化する必要があります。
「より良い」（私の頭のてっぺんから）は、サーバーにプログラムの作業を行わせ、プログラムに結果を表示させることです。次に、サーバーにアクセスできないクライアントの場合、サーバーに結果を返すことを拒否するだけです。
プログラムが Web サービスまたはその他のメカニズムを介した情報へのネットワーク アクセスに依存している場合は、遮断したいユーザー アカウントを単純にブラック リストに登録できます。
それが完全にオフラインのアプリケーションである場合、私の知る限り、あなたは SOL です。デプロイ後にアプリケーションを制御できるのは、まだ制御しているリソースへのネットワーク リクエストによるものだけです。
完全とは言えませんが、再考として、オフライン アプリケーションでは、技術的に熟練していないユーザーのみが、暗号化されたユーザー名のリストを通じてアプリケーションを無効にする更新メカニズムを通じてアプリケーションへのアクセスを制御しようとする可能性があります。ただし、その情報はすべてクライアント マシンに保存されるため、これは簡単に回避でき、元に戻される可能性があります。そして、ソフトウェアの更新を可能にするそれらに依存しています。
通常の方法は、一定期間の使用を許可するライセンスファイルを提供することです。その期間が過ぎると、ユーザーは新しいライセンスファイルを要求する必要があります。サーバーに直接接続せずに使用を許可する場合は、これが唯一の方法です。しかし、それはすべての関係者にとって厄介です。ユーザーは新しいライセンスファイルを要求することを余儀なくされ、あなたはそれらを作成して配布することを余儀なくされます。
サーバーに対する認証は可能ですが、Javaを使用している限り、安全性は高くありません。コードを難読化した場合でも、アプリケーションから認証部分を削除したり、認証トラフィックをスニッフィングしてモックサーバーを構築するだけで、ソフトウェアを永続的に有効にすることができます。暗号化方式で防ぐことはできますが、ますます複雑になっています。
厳密な制御を維持する最も簡単な方法は、アプリケーションの少なくとも一部をサービスとして提供することですが、もちろんそれにはサーバーが必要です。
サーバー側のコンポーネントがないと、求めているものは難しく、信頼性が低くなります。
ソフトウェアへのアクセスを取り消すことができることを保証する最良の方法は、インターネットベースの「サービスとしてのソフトウェア」アプリケーションを使用することです。アクセスを提供しない場合、彼らはソフトウェアを使用していません。デスクトップベースのアプリケーションの場合、重要な機能の一部は、オンラインサーバーのどこかにある必要があります。
ユーザーがローカルマシンにアプリケーション全体を持っている場合、それはリバースエンジニアリングされ、何らかの方法で「クラック」される可能性があります。これを克服する唯一の方法は、機能の一部がマシン上にないことを保証することです。
CPUハードウェアIDに基づいてシリアルを生成します。プログラムを定期的に更新し、特定のCPUSIDをハードコードでブラックリストに登録します。もちろん、定期的な更新が受信されていない場合は、プログラムを期限切れにする必要があります。
これは、ユーザーのマシンで実行されている実際のアプリケーションだと思います。
私が考えることができる最も簡単なアプローチは、Java Web Start を使用することです。これにより、アプリケーションを更新した場合に、アプリケーションがインターネットから jar をダウンロードできるようになります。これには、ユーザーごとのライセンスが含まれます (つまり、jnlp ファイルは、正しい jar を含めてダウンロードするユーザーに依存します)。そのライセンスにより、ユーザーは、インターネットにアクセスできなくても、アプリケーションを使用して数日間作業することができ、その後、新しいライセンスが必要になります。ダウンロードする必要があります (そのユーザーの JNLP ファイルが変更されたため)。注: 変更したライセンス ファイルの URL を変更する場合は、必ず確認してください。そうしないと、Java キャッシュが破損する可能性があります。
ライセンス ファイルには、日付を調べて true/false で続行するクラスを 1 つだけ含めることができます。密封された瓶を作成するには、適切な署名が必要です。
より高度なスキームが存在しますが、これは機能し、保守が簡単で、無料配布とハードコア ライセンス スキームの間の妥当な妥協点となります。
ユーザーが認証するためのある種の独立したリソースにアクセスできないため、私が考えることができる唯一の答えは、指定された時間間隔でユーザーにライセンスファイルを送信する「デッドマンズスイッチ」です。アプリケーションはこの間隔で「期限切れ」になり、実行するには新しいファイルが必要になります。ユーザーにソフトウェアを使用してほしくありませんか? 新しいファイルを送信しないでください。
これは、いくつかの理由から最適ではありません。
気にしないでください。実際のソフトウェアをクライアントに配布している限り、考えられるスキームを回避する方法は常にあります。最終的には、ソフトウェアの信頼性が低下し、操作が煩雑になるだけで、見込み顧客が怖がって離れてしまい、誰もが損をすることになります。
毎月、ユーザーは、プログラムに保存されている対応する月のユーザー名と一致する新しいユーザー名を入力する必要があります。ユーザーによるプログラムの使用を停止したい場合は、新しいユーザー名の送信を停止するだけで、月末以降はプログラムを使用できなくなります。
すべてのユーザーは一意のユーザー名を持つことができ、Web サービスと照合して、その特定のユーザーがまだ猶予リストにあるかどうかを確認できます。