D2LWS サービスの認証メカニズムは、API 呼び出し元を特権呼び出し元の立場に置きます。Valence Learning Framework API は異なる認証モデルを使用します。ユーザーを識別するユーザー ID/キー トークンは、呼び出しの機能を制限するためにバックエンドで使用されます。つまり、認証されたユーザーは、ユーザーが Web UI を介して取得するのと同じ機能とデータにアクセスできる必要があり、それ以上はアクセスできません。
この特定のケースでは、呼び出しは成功します。呼び出し元のユーザーが表示する権限を持っている結果セット内のすべての要素が返されますが、それらのいずれも返されません。
これはほぼ間違いなく、呼び出し元のユーザーに与えられたロール権限の問題であり、呼び出しに関する権限のデバッグは困難な場合があります。Valence プロジェクトのドキュメントには、特にユーザー レコード (またはユーザー レコードに表示されるプロパティ) へのアクセス権を取得するための呼び出しに関して、ここで可能なアプローチを可能にする可能性があるロール権限の調査に関するウォークスルー トピックが提供されています。
/d2l/api/lp/{version}/users/
ウォークスルーで説明しているように、アクセス許可を有効にする一般的な呼び出しを行うには、さまざまな側面があります。
クエリ パラメーターを使用してフィルター処理しようとしている場合、呼び出し元のユーザー コンテキストには、フィルター処理するデータを使用する権限がありますか?
呼び出し元のユーザー コンテキストには、ユーザー情報のプライバシー設定の影響を受けるプロパティを表示する権限がありますか?
呼び出し元のユーザーは、結果セットでユーザーを見つけるために、必要なすべてのユーザー ロールを検索する権限を持っていますか?
ユーザー呼び出しはルート組織単位で動作するため、呼び出し元のユーザーが必要とする権限は、組織組織単位タイプに設定する必要があります。
対照的に、成績関連の API 呼び出しは、ルート組織単位ではなく、通常、コースの提供、セクション、またはグループで動作します。そこでの通話に関する権限は、関連付けられた組織単位タイプでチェックされるため、呼び出し元のユーザーには、それらのタイプに対する適切な権限が必要になります。さらに、コース オファリング (セクションおよびグループも含む) に関連する呼び出しの多くでは、呼び出し元のユーザーが問題の組織単位に登録されている必要があります (場合によっては、カスケード登録によって単に登録されるのではなく、明示的に登録されます)。
呼び出し元のユーザー コンテキストがこれらのものへのアクセスを許可している (また、Web UI を介してこのデータにアクセスできる) ことが確実であり、API を介して呼び出しているときにこのような不一致が引き続き発生する場合は、何らかの欠陥が発見された可能性があります。組織のサポート担当者またはアカウント マネージャーにサポート チケットを開いて、Desire2Learn のサポート デスクを通じて報告するよう依頼してください。