2016-06-29 3 views
0

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

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

これを避けるための標準的なアプローチは何ですか?私が考えることができる唯一の解決策は、パッケージにLRSへのアクセス権を与えず、代わりにLMSを介してLRSにすべての要求をプロキシし、そのプロキシエンドポイントにパッケージにアクセスできるようにすることです。

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

答えて

0

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

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

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

関連する問題