本文概述
- API可能是无状态的, 人机交互不是
- 四千个Cookie
- 片段标识符
- 网络存储
- 索引数据库
- 总结
回想一下, 在SPA中, 典型的导航链接通常是片段标识符, 以井号(＃)开头。直接单击链接不会重新加载页面, 因此将保留JavaScript变量中存储的所有数据。但是, 如果我在新标签页或窗口中打开链接, 浏览器会重新加载页面, 并重新初始化所有JavaScript变量。因此, 除非你已采取措施以某种方式保留该数据, 否则绑定到这些变量的所有HTML元素都将显示不同。
文章图片
跨页面重新加载的持久数据：Cookie, IndexedDB及其之间的所有内容
鸣叫
如果我明确地重新加载页面(例如, 按F5键), 也会出现类似的问题。你可能认为我永远不需要按F5, 因为你已经建立了一种机制, 可以自动从服务器推送更改。但是, 如果我是普通用户, 可以打赌我仍然会重新加载页面。也许我的浏览器似乎没有正确地重新粉刷屏幕, 或者我只是想确定自己拥有最新的股票报价。
API可能是无状态的, 人机交互不是 与通过RESTful API发出的内部请求不同, 人类用户与网站的互动并非没有状态。作为网络用户, 我认为我对你网站的访问是一个会话, 几乎就像一个电话。我希望浏览器能够记住与我的会话有关的数据, 就像我打电话给你的销售或支持热线时一样, 我希望代表能够记住呼叫中先前所说的内容。
文章图片
会话数据的一个明显例子是我是否登录以及(如果已登录)哪个用户。进入登录屏幕后, 我应该能够自由浏览网站的用户特定页面。如果我在新标签页或窗口中打开链接, 并看到另一个登录屏幕, 则说明该界面不是很友好。
另一个示例是电子商务站点中购物车的内容。如果按F5键清空购物车, 则用户可能会感到不高兴。
在用PHP编写的传统多页应用程序中, 会话数据将存储在$ _SESSION超全局数组中。但是在SPA中, 它必须位于客户端的某个位置。在SPA中存储会话数据有四个主要选项：
- 曲奇饼
- 片段标识符
- 网络存储
- 索引数据库
文章图片
请记住, 无论页面重新加载还是Ajax请求, 你创建的任何cookie都会在每次请求时都发送到服务器。但是, 如果你需要存储的主要会话数据是已登录用户的访问令牌, 则无论如何, 你都希望将此数据发送到服务器。尝试使用这种自动cookie传输作为为Ajax请求指定访问令牌的标准方法是很自然的。
你可能会争辩说, 以这种方式使用cookie与RESTful体系结构不兼容。但是在这种情况下, 这很好, 因为通过API的每个请求仍然是无状态的, 具有一些输入和一些输出。只是其中一种输入是通过Cookie以有趣的方式发送的。如果你可以安排登录API请求也将访问令牌发送回cookie中, 那么你的客户端代码根本不需要处理cookie。同样, 它只是请求以不寻常的方式返回的另一个输出。
与网络存储相比, Cookie提供了一项优势。你可以在登录表单上提供” 保持登录状态” 复选框。使用语义, 我希望如果不检查它, 那么如果我重新加载页面或在新标签页或窗口中打开链接, 我将保持登录状态, 但是当关闭浏览器后, 我保证将注销。如果我使用共享计算机, 这是一项重要的安全功能。稍后我们将看到, 网络存储不支持此行为。
那么这种方法在实践中如何运作？假设你正在服务器端使用LoopBack。你已经定义了人员模型, 扩展了内置的用户模型, 并添加了要为每个用户维护的属性。你已将人员模型配置为通过REST公开。现在, 你需要调整server / server.js以获得所需的cookie行为。下面是server / server.js, 从slc loopback生成的内容开始, 带有已标记的更改：
var loopback = require('loopback');
var boot = require('loopback-boot');
var app = module.exports = loopback();
app.start = function() {
// start the web server
return app.listen(function() {
app.emit('started');
var baseUrl = app.get('url').replace(/\/$/, '');
console.log('Web server listening at: %s', baseUrl);
if (app.get('loopback-component-explorer')) {
var explorerPath = app.get('loopback-component-explorer').mountPath;
console.log('Browse your REST API at %s%s', baseUrl, explorerPath);
}
});
};
// start of first change
app.use(loopback.cookieParser('secret'));
// end of first change// Bootstrap the application, configure models, datasources and middleware.
// Sub-apps like REST API are mounted via boot scripts.
boot(app, __dirname, function(err) {
if (err) throw err;
// start of second change
app.remotes().after('Person.login', function (ctx, next) {
if (ctx.result.id) {
var opts = {signed: true};
if (ctx.req.body.rememberme !== false) {
opts.maxAge = 1209600000;
}
ctx.res.cookie('authorization', ctx.result.id, opts);
}
next();
});
app.remotes().after('Person.logout', function (ctx, next) {
ctx.res.cookie('authorization', '');
next();
});
// end of second change// start the server if `$ node server.js`
if (require.main === module)
app.start();
});
第一个更改将cookie解析器配置为使用” 秘密” 作为cookie签名秘密, 从而启用签名的cookie。你需要这样做, 因为尽管LoopBack会在Cookie的” 授权” 或” access_token” 中查找访问令牌, 但它要求对此类Cookie进行签名。实际上, 此要求毫无意义。签署Cookie旨在确保未修改Cookie。但是你不必修改访问令牌。毕竟, 你可能已经以普通的参数以无符号形式发送了访问令牌。因此, 除非你将签名的Cookie用于其他用途, 否则你不必担心很难猜测到Cookie的签名秘密。
第二个更改为Person.login和Person.logout方法设置了一些后处??理。对于Person.login, 你还想获取结果访问令牌并将其作为签名的cookie” 授权” 发送给客户端。客户端可以在凭据参数” rememberme” 中添加另一个属性, 以指示是否使cookie持续2周。默认值为true。 login方法本身将忽略此属性, 但后处理器将对其进行检查。
对于Person.logout, 你想清除此cookie。
你可以立即在StrongLoop API资源管理器中查看这些更改的结果。通常, 在Person.login请求之后, 你将必须复制访问令牌, 将其粘贴到右上角的表单中, 然后单击” 设置访问令牌” 。但是有了这些更改, 你无需执行任何操作。访问令牌会自动保存为Cookie” 授权” , 并在以后的每个请求中发送回去。当资源管理器显示来自Person.login的响应头时, 它会忽略cookie, 因为从不允许JavaScript看到Set-Cookie头。但是请放心, cookie在那里。
在客户端, 在重新加载页面时, 你会看到cookie” 授权” 是否存在。如果是这样, 则需要更新当前userId的记录。可能最简单的方法是在成功登录后将userId存储在单独的cookie中, 因此你可以在页面重新加载时检索它。
片段标识符 当我访问已实现为SPA的网站时, 浏览器地址栏中的URL可能类似于” https://example.com/#/my-photos/37″ 。其片段标识符部分” ＃/ my-photos / 37″ 已经是状态信息的集合, 可以将其视为会话数据。在这种情况下, 我可能正在查看我的一张照片, 即ID为37的照片。
文章图片
你可以决定将其他会话数据嵌入片段标识符中。回想一下, 在上一节中, 访问令牌存储在cookie” 授权” 中, 你仍然需要以某种方式跟踪userId。一种选择是将其存储在单独的cookie中。但是另一种方法是将其嵌入片段标识符中。你可以决定当我登录时, 我访问的所有页面都有一个以” ＃/ u / XXX” 开头的片段标识符, 其中XXX是userId。因此, 在上一个示例中, 如果我的userId为59, 则片段标识符可能是” ＃/ u / 59 / my-photos / 37″ 。
从理论上讲, 你可以将访问令牌本身嵌入片段标识符中, 从而无需使用Cookie或网络存储。但这将是一个坏主意。然后, 我的访问令牌将在地址栏中可见。任何人用相机看着我的肩膀都可以拍摄屏幕快照, 从而可以访问我的帐户。
最后一点：可以设置SPA, 使其完全不使用片段标识符。而是使用普通的网址(例如” http://example.com/app/dashboard” 和” http://example.com/app/my-photos/37″ ), 并将服务器配置为返回你的顶级HTML SPA, 以响应对任何这些URL的请求。然后, 你的SPA根据路径(例如” / app / dashboard” 或” / app / my-photos / 37″ )而不是片段标识符进行路由。它拦截对导航链接的单击, 并使用History.pushState()推送新URL, 然后照常进行路由。它还侦听popstate事件, 以检测用户单击” 后退” 按钮, 然后再次在已还原的URL上进行路由。如何实现此功能的完整细节超出了本文的范围。但是, 如果使用此技术, 则显然可以将会话数据而不是片段标识符存储在路径中。
网络存储 Web存储是JavaScript在浏览器中存储数据的一种机制。像cookie一样, 网络存储对于每个来源都是独立的。每个存储的项目都有一个名称和一个值, 它们都是字符串。但是Web存储对于服务器是完全不可见的, 并且它提供的存储容量比cookie大得多。 Web存储有两种类型：本地存储和会话存储。
文章图片
在所有窗口的所有选项卡上都可以看到一个本地存储项, 即使关闭浏览器后该项仍将保留。在这方面, 它的行为有点像具有过期日期的cookie。因此, 在用户在登录表单上选中” 保持登录状态” 的情况下, 适合存储访问令牌。
会话存储项仅在创建该选项卡的选项卡中可见, 并且在该选项卡关闭时消失。这使得它的生命周期与任何cookie的生命周期都非常不同。回想一下, 会话cookie在所有窗口的所有选项卡上仍然可见。
如果你将AngularJS SDK用于LoopBack, 则客户端将自动使用网络存储来保存访问令牌和userId。这发生在js / services / lb-services.js中的LoopBackAuth服务中。它将使用本地存储, 除非RememberMe参数为false(通常意味着未选中” 保持登录状态” 复选框), 在这种情况下, 它将使用会话存储。
结果是, 如果我在未选中” 保持登录状态” 的情况下登录, 然后在新标签页或窗口中打开链接, 则不会在此处登录。我很可能会看到登录屏幕。你可以自己决定这是否可以接受。有人可能会认为它是一个不错的功能, 你可以在其中具有多个选项卡, 每个选项卡均以不同的用户身份登录。或者, 你可能决定几乎没有人再使用共享计算机, 因此你可以完全省略” 保持登录状态” 复选框。
那么, 如果你决定使用AngularJS SDK for LoopBack, 会话数据处理将如何？假设你在服务器端的情况与以前相同：定义了Person模型, 扩展了User模型, 并通过REST公开了Person模型。你将不会使用Cookie, 因此无需进行任何上述更改。
在客户端, 最外面的控制器中的某处, 你可能有一个类似$ scope.currentUserId的变量, 该变量保存当前登录用户的userId；如果该用户未登录, 则为null。然后, 要正确处理页面重新加载, 你可以只需在该控制器的构造函数中包含以下语句：
$scope.currentUserId = Person.getCurrentId();
就这么简单。添加” 人员” 作为你控制器的依赖项(如果尚未添加)。
索引数据库 IndexedDB是用于在浏览器中存储大量数据的更新工具。你可以使用它来存储任何JavaScript类型的数据, 例如对象或数组, 而无需对其进行序列化。针对数据库的所有请求都是异步的, 因此在请求完成后你将获得回调。
你可以使用IndexedDB来存储与服务器上的任何数据都不相关的结构化数据。例如日历, 待办事项列表或在本地玩的已保存游戏。在这种情况下, 该应用程序实际上是本地应用程序, 而你的网站只是提供该应用程序的工具。
当前, Internet Explorer和Safari仅部分支持IndexedDB。其他主要的浏览器完全支持它。但是, 目前的一个严重限制是Firefox完全在私有浏览模式下禁用了IndexedDB。
作为使用IndexedDB的具体示例, 让我们以PavolDani?的滑动拼图应用程序为例, 并对其进行调整以保存第一个拼图的状态, 该动作是每次??移动后基于AngularJS徽标的Basic 3× 3滑动拼图。重新加载页面将恢复第一个难题的状态。
我用这些更改设置了存储库的分支, 所有这些更改都在app / js / puzzle / slidingPuzzle.js中。如你所见, IndexedDB的基本用法也涉及其中。我将在下面显示重点。首先, 在页面加载期间调用函数restore来打开IndexedDB数据库：
/*
* Tries to restore game
*/
this.restore = function(scope, storekey) {
this.storekey = storekey;
if (this.db) {
this.restore2(scope);
}
else if (!window.indexedDB) {
console.log('SlidingPuzzle: browser does not support indexedDB');
this.shuffle();
}
else {
var self = this;
var request = window.indexedDB.open('SlidingPuzzleDatabase');
request.onerror = function(event) {
console.log('SlidingPuzzle: error opening database, ' + request.error.name);
scope.$apply(function() { self.shuffle();
});
};
request.onupgradeneeded = function(event) {
event.target.result.createObjectStore('SlidingPuzzleStore');
};
request.onsuccess = function(event) {
self.db = event.target.result;
self.restore2(scope);
};
}
};
request.onupgradeneeded事件处理数据库尚不存在的情况。在这种情况下, 我们创建对象存储。
打开数据库后, 将调用函数restore2, 该函数将查找具有给定键的记录(在这种情况下, 该记录实际上是常量” Basic” )：
/*
* Tries to restore game, once database has been opened
*/
this.restore2 = function(scope) {
var transaction = this.db.transaction('SlidingPuzzleStore');
var objectStore = transaction.objectStore('SlidingPuzzleStore');
var self = this;
var request = objectStore.get(this.storekey);
request.onerror = function(event) {
console.log('SlidingPuzzle: error reading from database, ' + request.error.name);
scope.$apply(function() { self.shuffle();
});
};
request.onsuccess = function(event) {
if (!request.result) {
console.log('SlidingPuzzle: no saved game for ' + self.storekey);
scope.$apply(function() { self.shuffle();
});
}
else {
scope.$apply(function() { self.grid = request.result;
});
}
};
}
如果存在这样的记录, 则其值将替换难题的网格数组。如果在恢复游戏时出现任何错误, 我们只需像以前一样对游戏块进行洗牌。请注意, grid是3× 3的平铺对象数组, 每个对象都相当复杂。 IndexedDB的最大优点是你可以存储和检索这些值而无需序列化它们。
我们使用$ apply通知AngularJS模型已更改, 因此将适当更新视图。这是因为更新是在DOM事件处理程序中进行的, 因此AngularJS无法检测到更改。因此, 任何使用IndexedDB的AngularJS应用程序都可能需要使用$ apply。
在执行任何会更改网格数组的操作(例如用户的移动)之后, 将调用函数save, 该函数将基于更新的网格值使用适当的键来添加或更新记录：
/*
* Tries to save game
*/
this.save = function() {
if (!this.db) {
return;
}
var transaction = this.db.transaction('SlidingPuzzleStore', 'readwrite');
var objectStore = transaction.objectStore('SlidingPuzzleStore');
var request = objectStore.put(this.grid, this.storekey);
request.onerror = function(event) {
console.log('SlidingPuzzle: error writing to database, ' + request.error.name);
};
request.onsuccess = function(event) {
// successful, no further action needed
};
}
其余的更改是在适当的时候调用上述函数。你可以查看显示所有更改的提交。请注意, 我们仅将恢复称为基本难题, 而不是针对三个高级难题。我们利用三个高级拼图均具有api属性这一事实, 因此对于那些拼图, 我们只进行常规混洗。
如果我们也想保存和还原高级拼图怎么办？这将需要进行一些重组。在每个高级拼图中, 用户可以调整图像源文件和拼图尺寸。因此, 我们必须增强存储在IndexedDB中的值以包含此信息。更重要的是, 我们需要一种从还原中更新它们的方法。对于这个已经冗长的示例来说, 这有点多了。
总结 在大多数情况下, 网络存储是存储会话数据的最佳选择。所有主流浏览器都完全支持它, 并且它的存储容量比cookie大得多。
如果已经将服务器设置为使用Cookie, 或者需要在所有窗口的所有选项卡之间都可以访问数据, 则可以使用Cookie, 但是你还想确保在关闭浏览器时将其删除。
你已经使用片段标识符来存储特定于该页面的会话数据, 例如用户正在查看的照片的ID。尽管你可以将其他会话数据嵌入片段标识符中, 但与网络存储或Cookie相比, 这实际上没有任何优势。
【跨页面重新加载的持久数据（Cookie，IndexedDB及其之间的所有内容）】与其他任何技术相比, 使用IndexedDB可能需要更多的编码。但是, 如果你要存储的值是难以序列化的复杂JavaScript对象, 或者你需要事务模型, 那么这可能是值得的。
推荐阅读
- PHP 7简介（新增功能和已消失的功能）
- GWT工具包（使用Java构建强大的JavaScript前端）
- NodeOS（基于JavaScript的操作系统）
- 改善Meteor应用中项目结构的开发人员指南
- 使用循环片段依赖关系模块化单活动Android应用程序
- 从父活动android获取片段编辑文本值
- logcat错误android studio编程片段
- Android Stackoverflow错误（ViewGroup.jumpDrawablesToCurrentState）
- 在switch语句中将Android中的字符串从硬编码更改为字符串资源