注: これを振り返ってみると、多くの詳細が欠落しており、識別すべきエッジ ケースがたくさんあります。この形式のままにしておくのは、(詳細は完全には形成されていませんが) その感覚を提供することは有用であると考えているためです。ケースを適切に並べるには、脅威モデルを検討する必要があります。
パスワードに関しては、安全な接続 (TSL および https:) を使用する認証プロセスを使用することで、パスワードの共有を防ぐことができます。クライアント側では、マシンとユーザー アカウント (ユーザー ID とクライアント コンピューターのユーザー アカウント) に関連付けられたデータ。パスワードが判明したとしても、ハッシュ関数は別のマシンまたはユーザー アカウントで正しいハッシュを生成しません。
ハッシュ (これはあなたが受け入れるものであり、ユーザーが選択したパスワードを知ることは決してありません) が、使用されているユーザー ID と関連付けるために初めて確立される方法に関する興味深い問題があります。サブスクリプション用に提供され、サインアップ時に電子メール ハンドシェイクを介して提供され、ユーザー ID (電子メール アドレスと異なる場合) とパスワードを最初に選択する際に提供される一意のキーのようなものが必要になります。
ユーザーが繰り返しログインする必要がないように Cookie を使用する場合は、Cookie に暗号化/ハッシュ化された情報を入れて、マシンとサブスクリプションに関連付けることができます。
さて、これだけのことを行ったので、複数のマシンから作業できるようにしたいという問題があり、ユーザーのパスワードをリセットして、忘れた/侵害されたパスワードの代わりに新しいパスワードを選択できるようにする必要があります。これは、電話サポートや、正規のユーザーを再確認するその他の手段を提供することを意味するため、コストに見合う価値があるかどうか、またユーザーがコストに見合う価値があると考えるかどうかを検討する必要があります。
サイトから入手した資料の流用に関しては、もっと難しい問題があります。暗号化はあまり役に立たず、多くの場合、ユーザーがオフラインで使用するために資料を保持したり、資料を操作しながら参照したりできるようにしたいと考えています。すべての発生を切除することが困難な方法で特定の加入者に提供された場合。これは、サーバー側の多くの作業です。サブスクライバーに対する不信の明らかなデモンストレーションと組み合わせて、再考して、より信頼できるものを提供するように取り組み、たとえば、コンテンツを持っているだけでは反映されない価値のあるものを提供したいと思うかもしれません. よろしいですか?
注 2: コースウェアやレッスンに取り組むなど、何らかの進行を提供している場合、何らかの方法で複数の人が参加した場合、彼らが何らかの進歩を遂げた場合、物事を台無しにするためにできることは明らかです。他の誰かのために。パーソナライゼーションと進歩が進むほど、アカウントを他の誰かに提供して使用することは魅力的ではなくなります。これは素材の保持を妨げるものではありませんが、抽出されたコンテンツの広範な再利用には他の手段で対処する必要があります。