0

https://learninglocker.net/を LRS として使用して、xAPI 準拠の LMS を構築しています。管理者は、xAPI パッケージを含む zip ファイルをアップロードできます。LMS はそれを解凍し、起動ファイルを見つけて、ユーザーがその URL を起動できるようにし、LRS の資格情報をクエリ パラメーターとして渡します。パッケージは、LMS がそれを制御することなく、必要なものを LRS に直接報告できます。

さらに、LRS 資格情報は URL に表示されるため、技術に精通したユーザーはそれらを使用して必要なレコードを LRS に書き込むことができます。

これを回避するための標準的なアプローチは何ですか? 現在考えられる唯一の解決策は、パッケージに LRS へのアクセスを許可せず、代わりにすべてのリクエストを LMS 経由で LRS にプロキシし、パッケージにそのプロキシ エンドポイントへのアクセスを許可することです。

より良いアプローチはありますか?

4

1 に答える 1

0

プロキシ アプローチは機能するはずであり、LRS への負担は最小です。

私たちの実装では、LRS へのアクセス許可が制限された、自動生成された有効期間の短い (構成可能な) トークンを使用します。これには当然、LRS がそのようなことを可能にするパーミッション モデルの実装を必要とします。Learning Locker がそうするかどうか (またはそうするかどうか) はわかりません。このセットアップでは、ユーザーは引き続き LRS に直接アクセスできますが、アクセスが制限されているため、リスクは低くなります。

私の他の提案は、Tin Can 起動ガイドラインを実装するのではなく、cmi5 を調べることです (これはおそらくあなたが見つけたものです)。LRS パーミッション モデルには役立ちませんが、より標準的なパス上にあり、LMS モデルの xAPI ベースのコンテンツ専用です。

于 2016-06-29T14:11:18.250 に答える