シッククライアントの使用をやめ、これをWebベースのクライアントに移行する準備をすることをお勧めします。これにより、接続の中心点が可能になり、ユーザーがクライアントを更新する必要があるときに、ユーザーがクライアントを更新しないようにすることができます。
検討したいアーキテクチャは、Djangoなどのアプリケーションサーバーです(Pythonを使用しているため)。何が起こるかというと、アプリケーション(シンクライアント)をDjangoにデプロイすると、ユーザーはサーバーが吐き出すセッションを介してこのピースに接続するようになります。これにより、すべてのユーザーを1つの場所から管理し、必要に応じてスイッチを切り替えることができます。結局のところ、これにより、ソフトウェアとデスクトップクライアントのトラブルシューティングに費やす時間の両方のメンテナンスコストも削減されます。
コメント
たとえば、プログラムが起動し、サーバーに接続して、そこから設定を構築しますか?構成はどのように行われますか?プログラムにサーバーの変更を繰り返しチェックさせるだけですか、それとももっと良い方法がありますか?
それが機能する方法は、2種類の構成ファイルがあります。1つはユーザー定義です。たとえば、ユーザーがテキストを青で表示することを好み、その情報をサーバーが保存する場合、それらは通常ローカルに保存されるため、サーバーはそれを気にしません。
サーバー構成ファイルに関して、実行できることがいくつかあります。
ロールを介して権限を構成する
これには、ユーザーのロールに基づいてユーザーの権限を更新する必要があります。この更新が発生した場合、影響を受けるすべてのアクティブなセッションを終了して、新しいアクセス許可がそれらのユーザーにヒットするようにする必要があります。または、セッションが自動的にタイムアウトして新しいアクセス許可が取得されるのを待つことができます。
アプリケーションサーバーの設定
を変更する
これには、処理が必要なメンテナンスの問題、つまりパッチなど、アプリケーションを停止する必要があります。
プログラムはサーバーをポーリングせず、サーバーはクライアントにプッシュダウンします。それは完全には真実ではありません。クライアントはサーバーに接続し、新しいデータがある場合、クライアントは通常、ソケットを介してそれを受信します。セッションには情報の大部分が保存されるため、定期的に更新/破棄する必要があります(ログアウトなど)。
プログラムが設定を取得するという点では、そうです。ユーザーは、アプリケーションに接続する「ダミー」端末を持っています。これらのアカウントは通常、読み取り専用です。そのため、サーバーのコンテンツを変更することも、セキュリティ目的で変更することもできません。ユーザーが接続すると、アプリケーションはデータベースに接続して資格情報を取得します(証明書を使用することもできます。このアプローチをお勧めします)。ユーザーがアプリケーションに接続した資格情報に基づいて、その基本「プロファイル」をユーザーに提供し、サーバーが知っているユーザー固有の情報、つまり表示名/最終ログイン日を提供します。