我正在尝试使用以下服务在课程中动态创建组类别:
[/d2l/api/lp/(version)/(orgUnitId)/groupcategories/ \[POST\]][1]
以下是我发送给此服务的GroupData(Create form中的Group.GroupData)JSON块:
{
"Name": "New Group Category",
"Description": {
"Content": "",
"Type": "HTML"
},
"EnrollmentStyle": 0,
"EnrollmentQuantity": null,
"AutoEnroll": false,
"RandomizeEnrollments": false,
"NumberOfGroups": 5,
"MaxUsersPerGroup": null
}
我正在使用管理"实用程序"的用户上下文进行调用。帐户。我有2个测试课程,我已经确认我可以使用此实用程序帐户通过Web界面创建类别。
我的问题是我的结果好坏,这取决于我尝试创建类别的课程。在一门课程中课程返回200-OK,另一门则返回403-Forbidden。
以下是(简化的)请求:
致电1 /d2l/api/lp/1.4/350110/groupcategories/ 结果:403-Forbidden
致电2 /d2l/api/lp/1.4/19988/groupcategories/ 结果:200-OK
唯一的区别是OrgUnitID。版本,JSON和用户上下文都是一样的,但我得到了2个不同的结果。我曾尝试过其他几门课程,但我在一些课程中取得了成功,但并非全部取得了成功。总是收到403作为错误。
经过一番调查,我相信我发现成功的课程和返回403的课程有两个明显的区别。
所以我的想法是我们要么应用2012年3月下旬/ 4月初的补丁,它会以某种方式改变课程在创作时的标记,或者某种方式只有5位数(或更少?)服务接受组织ID。
我希望有人可以提供一些见解或验证他们对6位数的OUID和组类别创建没有任何问题。
答案 0 :(得分:0)
进一步审查API Responses - Disposition and error handling上的文档我意识到403响应有3种可能的情况:
鉴于此,我仔细研究了响应标题并意识到问题实际上是#2"无效令牌"而不是我假设的#3。
进一步调查我的代码似乎用户定义的SHA256函数我正在使用的是在被散列的数据长度恰好是55个字符时产生错误的HASH /签名(是的我意识到这听起来多么疯狂)。临时工作是用前导零填充我的OrgID,所以我的请求实际上也看起来类似:
/d2l/api/lp/1.4/00350110/groupcategories /
幸运的是,这似乎有效,并且在不久的将来是可以接受的。长期解决方案是用更可靠的东西取代我的SHA256功能。
我正在使用Colfusion 7MX进行开发,它没有本机SHA256哈希函数,因此使用了用户定义的函数。