如果我理解正确,您实际上并不关心 cookie,您关心的是拥有特定于用户的数据。
与 PHP 的比较
Meteor 客户端通过 DDP 与服务器通信,DDP 是 http 之上的抽象。DDP 级别中不存在诸如“cookies”之类的东西。相反,您可以访问强大的构造,例如同步的数据库集合和内置的远程过程调用。
Meteor 的Session
对象是为响应性而设计的仅限客户端的概念。它不会在客户端访问之间持续存在,并且服务器无权访问它。
大致相当于 PHP 的 SESSION 是 Meteor Collection,实际上它比 PHP 的 SESSION 更持久,因为它是持久化到数据库中的。
用户特定数据
在 Meteor 中跟踪用户特定的数据可以分为两部分:
- 经过身份验证的用户
- 匿名用户
回复:#1 - 经过身份验证的用户
正如@Tarang 和@Cuberto 所指出的,Meteor 帐户系统(例如帐户密码)具有内置的用户特定数据的概念。它为您创建和管理Meteor.users
集合,并提供Meteor.user()
获取特定于该用户的对象的功能。profile
它甚至在用户对象的字段中具有用于用户可修改数据的内置方法 。该profile
字段会自动发布并且也是响应式的(因为 Meteor.user() 是响应式的)。
function doSomething () {
var currentUser = Meteor.user(),
profile;
if (!currentUser) {
// handle 'not authenticated' case
} else {
// already logged in
profile = currentUser.profile || {name:'<not set>'};
console.log('user ', profile.name, ' wants to doSomething');
}
}
您可以构建自己的身份验证方法,但这似乎是灾难的根源。更容易编写从现有数据库结构转换为 Meteor Accounts 结构的脚本,并在准备好迁移用户时在大转储中执行一次。
所以 Meteor 约定是:
- 用户应该能够修改的用户特定数据进入该
user.profile
字段。前任。user.profile.firstname
,user.profile.lastname
- 受限制的用户特定数据应该放在根
user
对象上。
前任。meteor-roles包将用户角色存储在受限制的字段user.roles
中。
以下是相关文档:http ://docs.meteor.com/#meteor_user
回复:#2 - 匿名用户
Meteor Accounts 不会跟踪匿名用户,因此您需要自己跟踪他们。您可以使用各种方法来执行此操作,但核心是将一些识别令牌存储在客户端计算机上的客户端代码中(存储到 localStorage 或 cookie 中)。
如果您不需要在服务器上存储用户特定的数据,而只想更改客户端的内容,例如用户看到的内容,那么您可以从客户端完成所有操作。
如果您需要在服务器上为匿名用户存储数据,那么您必须将识别令牌连同每个 Meteor 方法调用或数据库交互(基本上就是 PHP 对 SESSION cookie 所做的事情)发送到服务器。在服务器上,创建一个名为“anonymousData”的集合,它将包含匿名用户的所有用户特定信息,由 id 令牌键入。服务器端函数可以使用客户端传递的 id 令牌查询该集合,以检索该用户的用户特定信息。
请记住,如果用户清除了他们的 cookie 或删除了 localStorage,则该数据将被孤立,因此某种最后使用的检查很重要。