翻译 Meteor React 制造 Todos - 10 - 要领的安全性

要领的平安性

在这个步骤之前,这款运用的任何用户都能够修正数据库的任何部份,在一个异常有意思的小项目或许演示项目中能够已不错了,然则任何一个实在的运用都须要对这些数据举行权限控制。
在Meteor上,最好的要领就是经由过程声明要领。以此来直接庖代客户端的代码。这些要领叫做insert, update, 另有remove,这将会替代实行的要领。它将会确认用户是不是有权限完成这么一整套操纵。那末随后在客户端中做出的任何对客户端的转变都邑发给数据库

移除 insecure

每一个新创建的Meteor项目都被默许的增加了insecure包。这个包许可我们从客户端中编辑数据库。在做产物原型的时刻这个包异常的有效,然则如今我们得关掉这个备胎。要移除这个包,我们得去运用目录下实行

meteor remove insecure

假如在移除这个包以后你试着去运用这款运用,你将会看到输入框或许是按钮都不能用了,这是由于统统的客户端数据库的权限被取消了,如今我们须要在我们的运用中经由过程运用一些要领来重写一些部份

定义一些要领

起首我们须要定义一些要领,我们须要一个要领,这个要领为我们定义了每一个数据库想在客户端实行的统统操纵。这些要领应该用代码定义,能够同时在客户端和服务端实行 — 我们会晚点儿在标题为“乐观的界面”的章节中继承议论

// simple-todos-react.jsx文件

    React.render(<App />, document.getElementById("render-target"));
  });
}

// 增加最先
Meteor.methods({
  addTask(text) {
    // 在插进去之前确保用户已上岸
    if (! Meteor.userId()) {
      throw new Meteor.Error("not-authorized");
    }
 
    Tasks.insert({
      text: text,
      createdAt: new Date(),
      owner: Meteor.userId(),
      username: Meteor.user().username
    });
  },
 
  removeTask(taskId) {
    Tasks.remove(taskId);
  },
 
  setChecked(taskId, setChecked) {
    Tasks.update(taskId, { $set: { checked: setChecked} });
  }
});
// 增加完毕

如今我们定义了我们的一些要领。我们须要去更新一些处所。我会要用方才定义好的要领去操纵数据库,而不是默许的。

// App.jsx文件中

// 经由过程React的ref属性来找到文本的字段
var text = React.findDOMNode(this.refs.textInput).value.trim();

// 增加最先
Meteor.call("addTask", text);
// 增加完毕

// Clear form
React.findDOMNode(this.refs.textInput).value = "";
// Tasks.jsx文件中
 
toggleChecked() {
  // 设置确认值为当前属性的相反值
  // 增加下一行
  Meteor.call("setChecked", this.props.task._id, ! this.props.task.checked);
},

deleteThisTask() {

    // 增加下面一行
  Meteor.call("removeTask", this.props.task._id);
},

render() {

如今,我们的输入和按钮又能用了,我们从这些工作中收成了什么呢?

  1. 当我们向数据库插进去数据的时刻,如今我们已能够平安的考证用户是不是登录,createdAt字段是不是是准确,ownerusername字段是不是是准确。一个用户不能模仿任何人了。

  2. 当用户想让使命成为隐私性子的时刻。我们能够在后面的步骤中给setCheckeddeleteTask增加分外的考证逻辑

  3. 我们的客户端代码和数据库逻辑越发的分离了。庖代了许多在事宜监听被触发的时刻的琐事。如今我们有了能够在任何处所被挪用的一些要领。

乐观的UI

那末我们为何要在服务端和客户端定义我们本身的要领呢。我们做这些是为了开启一个我们称之为“乐观的UI”的特征。

当我们在客户端嗲用Meteor.call要领的时刻,在这个时候点将会发作两件事变。

  1. 客户端向服务器端发送一个在平安环境下的要求。就像是AJAX那样的运转的要求。

  2. 一个要领模仿器直接会在客户端运转。它试图经由过程已有的信息来展望服务端返回的效果

这就意味着来自后端(服务器端)的效果抵达客户端之前,新创建的使命已现实地在屏幕上展示出来了。

假如从服务端返回的效果和在客户端模仿的效果一致,统统依然像之前所展示的一样。
假如从服务端返回的效果和在客户端模仿的效果不一致,那末界面将会补充上来自服务端的实在状况的回响反映。

控制了Meteor的一些“要领定义”和”乐观的UI“,你就得到了两个天下的精华 — 服务端代码的平安庇护和无传输耽误(no round-trip delay)。浏览blog post about optimistic UI能够相识更多这方面的学问

    原文作者:AnnatarHe
    原文地址: https://segmentfault.com/a/1190000003852512
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞