关于 xAPI，我似乎无法理解。我会尽量保持简单。（甚至可能是愚蠢的）
我的理解是真实的......
任何 Tin Can 实施的内容都可以使用启动器启动。 启动器提供端点和身份验证信息 端点不一定是 LRS。它可以是一个脚本，然后传递到最终端点，即 LRS。 LRS，在本例中为私有 SCORM 云（沙盒），无法接收没有基本身份验证的语句。
我需要知道的...
LRS 是否生成 OAuth 令牌？ 有人如何将 Captivate、Storyline、lectora 文件中的语句传递给 TinCan_PHP 以处理与 LRS 的安全连接？ 为什么我要使用 TinCan.JS，因为基本的身份验证信息很容易广播给最终用户，然后可以用来对 LRS 造成伤害？
我完全偏离轨道了吗？
非常感谢...
【问题讨论】：
标签： tin-can-api
只是对未来用户的一些澄清说明您的理解......
启动器可能提供端点和身份验证，这是一种情况，可能基于 0.9 规范中的launch guidelines。还有其他处理握手的方法，例如cmi5 是如何处理的（除了凭据只能被请求一次并且被故意拒绝某些特权（例如声明作废）之外，这不一定更安全） .
我认为您的“脚本”是“不符合标准的”LRS，因为它正在接收语句（以 xAPI 请求的形式），但不提供完整的 LRS 一致性。 SCORM Cloud 的 LRS 无法在没有一些身份验证的情况下接收语句，但您是正确的，基本是首选，因为 OAuth 对生产没有多大意义。
关于问题...
是的，LRS 生成 OAuth 令牌，但对于最常见的方法，内容必须与 LRS 已经建立关系并且基于 OAuth 的帐户必须在 LRS 上（或与 LRS 紧密耦合的系统，如 LMS）不 与一些野外的 OAuth 提供程序（意味着您不能使用 Twitter、Facebook 或 Google 等上的帐户）是经常让人困惑的部分）。
他们不会，这些产品都已经支持通过启动指南（基本身份验证）与 LRS 直接通信，与之通信的任何系统都必须至少具有足够的 LRS 功能来支持它们，其中包括除了 Statements API 之外的 State API。
TinCanJS 本身并不是浏览器唯一的解决方案，有人在服务器端运行它，所以语言确实是一个单独的问题。也可以在通用启动范式之外使用 TinCanJS，在这种情况下，用户有可能拥有相关 LRS（或与 LRS 耦合的系统）的个人凭据，并且他们自己输入。 bookmarklet 是一个很好的示例应用程序。
所有凭据集的底线是确保您的应用程序通过 https 与 LRS 进行对话，在这种情况下使用的凭据未公开，然后与 LRS 核对提供者查看是否可以使用寿命短且权限有限的凭据。除了使语句无效或覆盖（删除）存储的文档之外，对正确实施的 LRS 几乎没有什么“危害”，当使用适当的权限方案和有限的凭据时，这两者都可以受到限制。
【讨论】：
要回答您的问题，是的，您完全偏离了轨道！ :-)
如果您将基于 javascript 的电子学习课程中的语句发送到某处，那么连接本身就是不安全的。在不安全的连接之后在链中添加另一个（安全或其他）链接不会增加您的安全性。您也可以将 xAPI 语句直接发送到 LRS。
您也可以使用基本 HTTP 身份验证。首先，这是所有创作工具都支持的，所以你必须这样做。其次，使用 OAuth 而不是 Basic Auth 进行客户端连接就像使用钥匙锁而不是组合锁，然后将钥匙留在垫子下。钥匙锁 (OAuth) 在理论上可能比密码锁 (Basic Auth) 更安全，但如果您将钥匙留在门垫下（嵌入在客户端代码中），则实际上并非如此。
请参阅此SO question answer，了解您可以对 xAPI 身份验证安全性所做的三个选项。
为了完整起见：是的，在 OAuth 的情况下，LRS 会生成令牌。请参阅xAPI spec 了解最新的详细信息。
【讨论】：