1

关于 xAPI，我似乎有些难以理解。我会尽量保持简单。（甚至可能是愚蠢的）

我理解的都是真的……

任何 Tin Can 实施的内容都可以使用启动器启动。启动器提供端点和身份验证信息端点不一定是 LRS。它可以是一个脚本，然后传递到最终端点，即 LRS。LRS，在这种情况下是私有的 SCORM 云（沙盒），无法接收没有基本身份验证的语句。

我需要知道的...

LRS 是否生成 OAuth 令牌？有人如何将 Captivate、Storyline、lectora 文件中的语句传递给 TinCan_PHP 以处理与 LRS 的安全连接？为什么我要使用 TinCan.JS，当基本的身份验证信息很容易广播给最终用户时，这些信息可能会被用来对 LRS 造成伤害？

我完全偏离轨道了吗？

非常感谢...

4

2 回答 2

3

只是对未来用户的一些澄清，以了解您的理解......

启动器可以提供端点和身份验证，这是一种情况，可能基于0.9 规范中的启动指南。还有其他处理握手的方法，例如cmi5是如何处理的（除了凭据只能被请求一次并且被故意拒绝某些特权（例如声明无效）之外，这不一定更安全）。

我认为您的“脚本”是“不符合标准”的 LRS，因为它正在接收语句（以 xAPI 请求的形式），但不提供完整的 LRS 一致性。SCORM Cloud 的 LRS 无法在没有一些身份验证的情况下接收语句，但您是正确的基本是首选，因为那里的 OAuth 对生产没有多大意义。

对于问题...

  1. 是的，LRS 生成 OAuth 令牌，但对于最常见的方法，内容必须与 LRS 建立已建立的关系，并且基于 OAuth 的帐户必须位于 LRS（或 LRS 紧密耦合的系统，例如LMS）不与一些野外的 OAuth 提供者一起使用（这意味着您不能在 Twitter、Facebook 或 Google 等上使用帐户，这是经常让人们感到困惑的部分）。

  2. 他们不会，这些产品都已经支持通过启动指南（基本身份验证）与 LRS 直接通信，他们与之通信的任何系统都必须至少具有足够的 LRS 功能来支持它们，其中包括除了 Statements API 之外的 State API .

  3. TinCanJS 本身并不是浏览器唯一的解决方案，有人在服务器端运行它，所以语言确实是一个单独的问题。也可以在通用启动范式之外使用 TinCanJS，在这种情况下，用户有可能拥有相关 LRS（或与 LRS 耦合的系统）的个人凭据，并且他们自己输入。小书签是一个很好的示例应用程序。

所有凭据集的底线是确保您的应用程序通过 http 与 LRS 进行对话，在这种情况下，使用的凭据未公开，然后与 LRS 提供者核实是否可以使用凭据寿命短且权限有限。除了使语句无效或覆盖（删除）存储的文档之外，对正确实施的 LRS 几乎没有什么“危害”，当使用适当的权限方案和有限的凭证时，这两者都可以受到限制。

于 2015-12-17T13:55:22.563 回答
2

要回答您的问题，是的，您完全偏离了轨道！:-)

如果您将基于 javascript 的电子学习课程中的语句发送到某个地方，那么连接本身就是不安全的。在不安全的连接之后在链中添加另一个（安全或其他）链接不会增加您的安全性。您也可以将 xAPI 语句直接发送到 LRS。

您也可以使用基本 HTTP 身份验证。首先，这是所有创作工具都支持的，所以你必须这样做。其次，使用 OAuth 而不是 Basic Auth 进行客户端连接就像使用钥匙锁而不是组合锁，然后将钥匙留在垫子下。从理论上讲，钥匙锁 (OAuth) 可能比密码锁 (Basic Auth) 更安全，但如果您将钥匙留在门垫下（嵌入客户端代码中），则实际上并非如此。

有关 xAPI 身份验证安全性的三个选项，请参阅此SO 问题答案。

只是为了完整起见：是的，在 OAuth 的情况下，LRS 会生成令牌。有关最新的详细信息，请参阅xAPI 规范。

于 2015-12-17T11:20:06.393 回答