3

Service Workerは基本的に、Web アプリケーション間に配置されるプロキシ サーバーとして機能します。

私の懸念: ServiceWorkerはオフライン フォームもサポートしていますか? - もしそうなら、私の他の懸念事項のリストは次のとおりです。

  1. クライアント側 (ストレージ、セッション、ローカル、データベース) で不完全な HTML フォーム データを保存した場所は?
  2. ユーザーが入力したデータをどの形式で保存するか (暗号化など)
  3. データのセキュリティ/プライバシーはどのように取り組まれましたか? 戻ってきたユーザーが同じユーザーであることを確認しますか? - 1 人のユーザーが公共の場所でフォームに記入し、インターネット接続が失われ、不完全なフォームを離れて移動した場合、次の直接のユーザーは、最後のユーザーがフォームを離れた場所の不完全なフォーム データを見ることができます。
4

1 に答える 1

4

まず、Service Worker は多くのことを実行できる可能性があります。たとえば、彼らはIndexedDBにアクセスできるため、制御されたページまたは Service Worker のいずれかのコンテキストから、任意のデータを保存およびロードする可能性が常にあります。

しかし、Service Worker を登録したからといって、自動的に行われるわけではありません。Service Worker はデフォルトで何もしません。Service Worker にさまざまなイベント ( installfetchmessageなど) にフックするコードを記述して初めて、興味深いことがわかります。

仮説として、HTML リソースの HTTP 応答をキャッシュし、そのキャッシュされたfetch応答で要求の URL のイベントに応答する Service Worker にコードを記述した場合、ブラウザーは元に戻り、同じ HTML をレンダリングします。応答はネットワークから来ていました。HTML 応答本文と共にキャッシュされる特別な「フォーム状態」はありません。

なんらかの理由で、「フォームの状態」を保存して、フォームのあるページを離れたユーザーが戻って編集を続けることができるようにしたい場合はcaches、Service Worker に公開されているオブジェクトとは別にそれを行う必要があります。(オブジェクトをキーとして使用し、オブジェクトを値として格納cachesする必要があります。)RequestResponse

したがって、潜在的に を使用して実行することも、 を使用して実行することも、実際にはその他のIndexedDBものを使用することもできlocalStorageます。これは Service Worker から独立しており、特定のプライバシー/セキュリティの考慮事項は実装者次第です。

于 2015-02-17T21:26:00.787 に答える