1

xAPIに関して何かが私を逃しているようです。私はこれを本当にシンプルにしようとしています.(そして多分ばかです)

私が真実だと理解していること...

Tin Can で実装されたコンテンツは、ランチャーで起動できます。ランチャーは、エンドポイントと認証情報を提供します。エンドポイントは LRS である必要はありません。これは、LRS である最終エンドポイントに渡されるスクリプトにすることができます。LRS、この場合はプライベート SCORM クラウド (サンドボックス) は、基本認証なしではステートメントを受信できません。

私が知る必要があること...

LRS は OAuth トークンを生成しますか? LRS への安全な接続を処理するために、Captivate、Storyline、lectora ファイルから TinCan_PHP にステートメントを渡すにはどうすればよいでしょうか? 基本的な認証情報がエンドユーザーに簡単にブロードキャストされ、LRS に害を及ぼすために使用される可能性があるのに、なぜ TinCan.JS を使用するのでしょうか?

私は完全に軌道から外れていますか？

どうもありがとう...

4

2 に答える 2

3

ご理解の上、将来のユーザーのためにいくつかの説明をしてください...

ランチャーはエンドポイントと認証を提供する場合があります。これは 1 つのシナリオであり、おそらく0.9 仕様で発表された起動ガイドラインに基づいています。ハンドシェイクを処理する方法は他にもあります。たとえば、cmi5の方法などです(これは、資格情報が 1 回しか要求できず、ステートメントの無効化などの特定の特権が意図的に拒否されているという事実を除けば、必ずしも安全であるとは限りません)。

あなたの「スクリプト」は、(xAPI 要求の形式で) ステートメントを受信して​​いるという点で「非準拠」の LRS と見なされますが、完全な LRS 準拠は提供されません。SCORM クラウドの LRS は認証なしではステートメントを受け取ることができませんが、OAuth は本番環境ではあまり意味がないため、ベーシックが優先されます。

質問に対して...

  1. はい、LRS は OAuth トークンを生成しますが、最も一般的なアプローチでは、コンテンツはその LRSと既に確立された関係を持っている必要があり、OAuth ベースのアカウントは LRS (または、LRS が密接に結合されているシステム) にある必要があります。 LMS)は、一部の OAuth プロバイダーでは使用できません (つまり、Twitter、Facebook、または Google などのアカウントを使用できないことを意味します。これは、人々を混乱させることがよくある部分です)。

  2. これらの製品はすべて、起動ガイドライン (基本認証) を介した LRS への直接通信を既にサポートしています。通信しているシステムには、ステートメント API に加えて State API を含む、それらをサポートするのに少なくとも十分な LRS 機能が必要です。 .

  3. TinCanJS 自体はブラウザーのみのソリューションではありません。サーバー側で実行している人がいるため、言語は実際には別の問題です。共通の起動パラダイムの外で TinCanJS を使用することもできます。そのような状況では、ユーザーが問題の LRS (または LRS と結合されたシステム) で個人の資格情報を持っていて、それを自分で入力することができます。ブックマークレットはアプリケーションの良い例です。

資格情報のすべてのセットの要点は、アプリケーションが http を介して LRS と通信していることを確認することです。この場合、使用される資格情報は公開されていません。次に、資格情報を使用できるかどうかを LRS プロバイダーに確認してください。有効期間が短く、アクセス許可が制限されています。ステートメントの無効化または保存されたドキュメントの上書き (削除) を除いて、適切に実装された LRS に対して実行できる「害」はほとんどありません。これらはどちらも、適切なアクセス許可スキームと制限された資格情報を使用する場合に制限できます。

于 2015-12-17T13:55:22.563 に答える
2

あなたの質問に答えるには、はい、あなたは完全に軌道から外れています! :-)

JavaScript ベースの e ラーニング コースからステートメントをどこかに送信している場合、接続は本質的に安全ではありません。その安全でない接続の後にチェーンに別の (安全またはその他の) リンクを追加しても、セキュリティは強化されません。xAPI ステートメントを LRS に直接送信することもできます。

基本 HTTP 認証も使用できます。まず、これはすべてのオーサリング ツールがサポートしているものなので、そうしなければなりません。次に、クライアント側の接続に Basic Auth の代わりに OAuth を使用することは、コンビネーション ロックの代わりにキー ロックを使用し、キーをマットの下に置いておくようなものです。キー ロック (OAuth) はコンビネーション ロック (Basic Auth) よりも理論的には安全かもしれませんが、キーをドアマットの下に置いたままにしておくと (クライアント側のコードに埋め込まれます)、実際にはそうではありません。

xAPI 認証セキュリティについて実行できる3 つのオプションについては、このSO の質問の回答を参照してください。

完全を期すために: はい、OAuth の場合、LRS がトークンを生成します。最新の詳細については、 xAPI 仕様を参照してください。

于 2015-12-17T11:20:06.393 に答える