CL。デスクトップ アプリケーションから Web データベースにアクセスする必要がある場合、SQLite は適切な選択ではないと言っているのは正しいことです。
SQLite の使用は、小さな Web サイト、つまり Web サイト自体からのみデータにアクセスする必要があるアプリケーションでは問題ありません。しかし、データ ファイルをダウンロードせずにデスクトップなどからデータにアクセスする必要がある場合、SQLite と HTTP ではそれを実現できません。
Web アプリケーションに適切な選択肢は、MySQLまたはその他のクライアント/サーバー データベースです。これにより、サーバー アクセス ルール セットがそれを許可する場合 (ファイアウォール、付与されたファイアウォールなど)、Web アプリケーション以外の任意の場所からデータベース サービスに接続できます。認証など)。
使用シナリオでは、いくつかの問題に直面することになります。
1) セキュリティ
データベース ファイルは直接 Web に公開されないように保護する必要があるという安全原則に違反することになります。実際、デスクトップから Web SQLite データベース ファイルにアクセスするには、それを直接公開する必要があります。これは間違いです。誰もがファイルをダウンロードしてデータにアクセスできるためです。定義上、データには自分だけがアクセスできる必要があります。
2) ダウンロードせずに更新可能
HTTP を使用してデータベース ファイルへのアクセスを取得すると、要求されたリソースのダウンロードのみにつながる可能性があります。HTTP はステートレス プロトコルであるため、データベースへの GET または POST アクセスを要求すると、Web サーバーは 1 つのソリューションでそれを提供します。フルストップ。極端な統合では、変更をデータベース ファイルに直接書き戻す機会はありません。
3) ダウンロードによる更新可能性
HTTP GET 要求を使用してファイルをダウンロードし、データを読み取り、変更を加えることができますが、その間にオンライン データベースが変更された場合はどうなるでしょうか? データの一貫性は簡単に損なわれます。
方法があるかもしれません
デスクトップ アプリケーションのデータベースへのアクセスに HTTP を使用することをあきらめた場合は、FTP を選択できます (リソースへのアクセス資格情報がある場合)。FTP を使用するとファイルからデータを読み書きできるため、Linux では FUSE を使用してリモート FTP 共有をマウントし、ローカル ファイル システムに接続されているかのようにアクセスできます (たとえば、この記事を参照してください)。
合成では、次のことを行います。
- FTP 共有用のマウント ポイント (つまり、ローカル ディレクトリ) を作成します。
curlftpfs
リモート FTP リソースをマウント ポイントにリンクするために使用します
- 従来のディレクトリであるかのように、アプリケーションからこのディレクトリにアクセスします
このようにして、セキュリティを維持し、データベース ファイルが Web 上に公開されないようにし、デスクトップ アプリケーションからアクセスできるようにします。
とは言っても、複数のプロセス (デスクトップ アプリ + Web サーバー インスタンス) による単一のデータベース ファイルへの同時アクセスが問題を引き起こす可能性があることを考慮してください (アイデアについては、この SO 投稿を参照してください)。ソリューションを設計する前に、このことを念頭に置いてください。
最後に、使用シナリオでの私の提案は、サーバー側の Web サービスまたは REST インターフェイスをプログラムすることです。これにより、認証の下で、必要な主要な操作を実行するデータベース ファイルと対話できます。
安全で信頼性が高く、やりたいことが何でもできる「プラスチック」です。
編集:
MySQL は、高速で非常にスケーラブルで、適度に信頼できるため、Web サイトまたは Web アプリケーションで広く使用されています。MySQL サーバーのアクティブ化は、StackOverflow では少し OT であり、報告するにはかなり長い時間がかかります。
次に、MySQL JDBC ドライバーを使用して、Java デスクトップ アプリケーションからデータベースにアクセスします。
ただし、SQLite に固執する場合は、基本的に 4 つの Web エンドポイントを用意できます。
- http://yourwebsite.com/select
- http://yourwebsite.com/insert
- http://yourwebsite.com/update
- http://yourwebsite.com/delete
(「http」を指定したことに注意してください。ただし、SSL 暗号化された http 接続、別名「https」に移行することを検討することもできます。詳細については、こちらとこちらを参照してください。実行している Web サーバーはわかりませんが、少しグーグルで調べてみるとわかります。 https を適切に構成するための適切なリソースにアクセスしてください。)
明らかに、任意の種類の操作に好きなエンドポイントを追加できますが、より一般的なexecute
.
これらのエンドポイントへのリクエストは POST であり、すべてのエンドポイントは次のような適切なパラメーターを受け取ります。
... などですが、最も重要なのはセキュリティであるため、次の 2 つのことを覚えておく必要があります。
1. すべての要求に署名します。これを実現するには、秘密の操作キー (クライアントとサーバーに知られているが、平文では送信されない文字列) を定義し、それをハッシュ関数で使用して、他のパラメーターと共に議論の余地のないものとして送信されるダイジェストを生成します。サーバーが受信しているリクエストが本物のソースからのものであることを証明します。これにより、リクエストごとにユーザー名とパスワードを送信する必要がなくなります。これにより、https を使用しない場合にパスワード暗号化の問題が発生し、サーバーが同じアルゴリズムを使用して同じリクエストに対して同じ署名を再構築できる必要があります。 . (私は時速 400 マイルでこの物体の上を飛行しましたが、トピックが大きすぎてここで正しく処理できません。とにかく、これが正しい方向に向けられることを願っています。)
2. リクエスト パラメータを適切にエスケープします。「サニタイズ」パラメータと誰かが呼んでいますが、その比喩は正しいと思います。一般的に言えば、このプロセスにはサーバーのエンドポイントによって実行されるフィルタリング操作が含まれますが、基本的には「クエリに準備済みステートメントを使用する」と記述できます。そうしないと、悪意のある攻撃者がリクエストに SQL コードを挿入して、何らかの方法でサーバーを悪用する可能性があります。