在列表中点进详情，从详情页浏览器后退到表格时，表格当前页不变

方法一：使用js来实现

使用到的方法：

history.pushState()
history.pushState() 方法向当前浏览器会话的历史堆栈中添加一个状态（state）。

语法：history.pushState(state, title[, url])

参数：

state
状态对象是一个JavaScript对象，它与pushState()创建的新历史记录条目相关联。 每当用户导航到新状态时，都会触发popstate事件，并且该事件的状态属性包含历史记录条目的状态对象的副本。
状态对象可以是任何可以序列化的对象。 因为Firefox将状态对象保存到用户的磁盘上，以便用户重新启动浏览器后可以将其还原，所以我们对状态对象的序列化表示施加了640k个字符的大小限制。 如果将序列化表示形式大于此状态的状态对象传递给pushState()，则该方法将引发异常。 如果您需要更多空间，建议您使用== sessionStorage或者localStorage==。
title
当前大多数浏览器都忽略此参数，尽管将来可能会使用它。 在此处传递空字符串应该可以防止将来对方法的更改。 或者，您可以为要移动的州传递简短的标题。
url可选
新历史记录条目的URL由此参数指定。 请注意，浏览器不会在调用pushState() 之后尝试加载此URL，但可能会稍后尝试加载URL，例如在用户重新启动浏览器之后。 新的URL不必是绝对的。 如果是相对的，则相对于当前URL进行解析。新网址必须与当前网址相同 origin； 否则，pushState()将引发异常。 如果未指定此参数，则将其设置为文档的当前URL。

示例：

const state = { 'page_id': 1, 'user_id': 5 }
const title = ''
const url = 'hello-world.html'

history.pushState(state, title, url)

需求中实现：

实现思路：

点进详情页时，给state中添加一个当前页码属性nowPage。在加载列表时，判断是否存在window.history.state.nowPage，则说明是从详情页回退过来的，需要在请求列表接口时传入当前页参数。
注意要清空window.history.state.nowPage，不然会导致回退后无法翻页！

代码：

点进详情页

var state = {
    nowPage: this.listPage.current
};
window.history.pushState(state, "nowPage");

加载列表：

// 若从操作页面过来，则记录了当前页
let nowPage = window.history.state ? window.history.state.nowPage : '';
if(nowPage){
    this.listPage.current = window.history.state.nowPage;
    window.history.state.nowPage = '';
}

方法二：Vue项目中，可以使用路由挂钩

使用到的函数：

beforeRouteEnter、beforeRouteUpdate、beforeRouteLeave
参考文章：Vue的生命周期函数和beforeRouteEnter()/beforeRouteLeave()函数

Storage(Local Storage & Session Storage & Cookies)

作为Web Storage API的接口，Storage提供了访问特定域名下的会话存储或本地存储的功能，例如，可以添加、修改或删除存储的数据项。

方法：

Storage.key()
该方法接受一个数值 n 作为参数，并返回存储中的第 n 个键名。
Storage.getItem()
该方法接受一个键名作为参数，返回键名对应的值。
Storage.setItem()
该方法接受一个键名和值作为参数，将会把键值对添加到存储中，如果键名存在，则更新其对应的值。
Storage.removeItem()
该方法接受一个键名作为参数，并把该键名从存储中删除。
Storage.clear()
调用该方法会清空存储中的所有键名。

Local Storage

如果想要操作一个域名的本地存储，可以使用 Window.localStorage。
只读的localStorage属性允许你访问一个Document 源（origin）的对象 Storage；存储的数据将保存在浏览器会话中。localStorage 类似 sessionStorage，但其区别在于：存储在localStorage的数据可以长期保留；而当页面会话结束——也就是说，当页面被关闭时，存储在sessionStorage的数据会被清除 。

示例：

下面的代码片段访问了当前域名下的本地 Storage 对象，并通过 Storage.setItem() 增加了一个数据项目。

localStorage.setItem('myCat', 'Tom');

该语法用于读取 localStorage 项，如下:

let cat = localStorage.getItem('myCat');

该语法用于移除 localStorage 项，如下:

localStorage.removeItem('myCat');

该语法用于移除所有的 localStorage 项，如下:

// 移除所有
localStorage.clear();

Session Storage

如果想要操作一个域名的会话存储，可以使用Window.sessionStorage。
sessionStorage属性允许你访问一个，对应当前源的 session Storage 对象。它与 localStorage 相似，不同之处在于localStorage里面存储的数据没有过期时间设置，而存储在sessionStorage里面的数据在页面会话结束时会被清除。

• 页面会话在浏览器打开期间一直保持，并且重新加载或恢复页面仍会保持原来的页面会话。
• 在新标签或窗口打开一个页面时会复制顶级浏览会话的上下文作为新会话的上下文，这点和 session cookies 的运行方式不同。
• 打开多个相同的URL的Tabs页面，会创建各自的sessionStorage。
• 关闭对应浏览器窗口（Window）/ tab，会清除对应的sessionStorage。

应该注意，存储在sessionStorage或localStorage中的数据特定于页面的协议。也就
是说http://example.com与https://example.com的sessionStorage相互隔离。
被存储的键值对总是以UTF-16 DOMString 的格式所存储，其使用两个字节来表示一个字符。对于对象、整数key值会自动转换成字符串形式。

语法：

// 保存数据到 sessionStorage
sessionStorage.setItem('key', 'value');

// 从 sessionStorage 获取数据
let data = sessionStorage.getItem('key');

// 从 sessionStorage 删除保存的数据
sessionStorage.removeItem('key');

// 从 sessionStorage 删除所有保存的数据
sessionStorage.clear();

返回值：

一个 Storage对象。

示例：

下面的代码访问当前域名的 session Storage对象，并使用Storage.setItem()访问往里面添加一个数据条目。

sessionStorage.setItem('myCat', 'Tom');

下面的示例会自动保存一个文本输入框的内容，如果浏览器因偶然因素被刷新了，文本输入框里面的内容会被恢复，因此写入的内容不会丢失。

// 获取文本输入框
let field = document.getElementById("field");
 
// 检测是否存在 autosave 键值
// (这个会在页面偶然被刷新的情况下存在)
if (sessionStorage.getItem("autosave")) {
  // 恢复文本输入框的内容
  field.value = sessionStorage.getItem("autosave");
}
 
// 监听文本输入框的 change 事件
field.addEventListener("change", function() {
  // 保存结果到 sessionStorage 对象中
  sessionStorage.setItem("autosave", field.value);
});

Cookies

简介

Cookie，有时也用其复数形式 Cookies。类型为==“小型文本文件”，是某些网站为了辨别用户身份==，进行Session跟踪而储存在用户本地终端上的数据（通常经过加密），由用户客户端计算机暂时或永久保存的信息。
举例来说, 一个 Web 站点可能会为每一个访问者产生一个唯一的ID, 然后以== Cookie 文件的形式保存在每个用户的机器上==。如果使用浏览器访问 Web, 会看到所有保存在硬盘上的 Cookie。在这个文件夹里每一个文件都是一个由“名/值”对组成的文本文件,另外还有一个文件保存有所有对应的 Web 站点的信息。在这里的每个 Cookie 文件都是一个简单而又普通的文本文件。透过文件名, 就可以看到是哪个 Web 站点在机器上放置了Cookie(当然站点信息在文件里也有保存) 。

组成

Cookie是一段不超过4KB的小型文本数据，由一个名称（Name）、一个值（Value）和其它几个用于控制Cookie有效期、安全性、使用范围的可选属性组成。其中 ：
(1)Name/Value：设置Cookie的名称及相对应的值，对于认证Cookie，Value值包括Web服务器所提供的访问令牌。
(2)Expires属性：设置Cookie的生存期。有两种存储类型的Cookie：会话性与持久性。Expires属性缺省时，为会话性Cookie，仅保存在客户端内存中，并在用户关闭浏览器时失效；持久性Cookie会保存在用户的硬盘中，直至生存期到或用户直接在网页中单击“注销”等按钮结束会话时才会失效。
(3)Path属性：定义了Web站点上可以访问该Cookie的目录。
(4)Domain属性：指定了可以访问该 Cookie 的 Web 站点或域。Cookie 机制并未遵循严格的同源策略，允许一个子域可以设置或获取其父域的 Cookie。当需要实现单点登录方案时，Cookie 的上述特性非常有用，然而也增加了 Cookie受攻击的危险，比如攻击者可以借此发动会话定置攻击。因而，浏览器禁止在 Domain 属性中设置.org、.com 等通用顶级域名、以及在国家及地区顶级域下注册的二级域名，以减小攻击发生的范围。
(5)Secure属性：指定是否使用HTTPS安全协议发送Cookie。使用HTTPS安全协议，可以保护Cookie在浏览器和Web服务器间的传输过程中不被窃取和篡改。该方法也可用于Web站点的身份鉴别，即在HTTPS的连接建立阶段，浏览器会检查Web网站的SSL证书的有效性。但是基于兼容性的原因（比如有些网站使用自签署的证书）在检测到SSL证书无效时，浏览器并不会立即终止用户的连接请求，而是显示安全风险信息，用户仍可以选择继续访问该站点。由于许多用户缺乏安全意识，因而仍可能连接到Pharming攻击所伪造的网站。
(6)HTTPOnly属性 ：用于防止客户端脚本通过document.cookie属性访问Cookie，有助于保护Cookie不被跨站脚本攻击窃取或篡改。但是，HTTPOnly的应用仍存在局限性，一些浏览器可以阻止客户端脚本对Cookie的读操作，但允许写操作；此外大多数浏览器仍允许通过XMLHTTP对象读取HTTP响应中的Set-Cookie头。

安全威胁

Cookie捕获/重放

攻击者可以通过木马等恶意程序，或使用跨站脚本攻击等手段偷窃存放在用户硬盘或内存中的Cookie。借助网络攻击手段，包括在不安全的局域网中被动地监听网络通信；通过攻击网络用户的路由器，或通过搭建恶意的无线路由器等手法，控制路由基础设施，将网络流量重定向到攻击者控制的主机；发动DNSPharming(域欺骗)攻击，通过DNS缓存中毒、DNS应答欺骗、或修改用户端的本地域名解析文件等方法攻击DNS系统，导致用户对合法网站的访问请求被重定向到恶意网站等等，同样可能窃取Cookie。对于捕获到的认证Cookie，攻击者往往会猜测其中的访问令牌，试图获取会话ID、用户名与口令、用户角色、时间戳等敏感信息；或者直接重放该Cookie，假冒受害者的身份发动攻击。

恶意 Cookies

Cookies 是文本文件， 一般情况下认为它不会造成安全威胁。 但是，如果在 Cookies 中通过特殊标记语言，引入可执行代码，就很可能给用户造成严重的安全隐患。HTML 为区别普通文本和标记语言，用符号“<>”来指示HTML 代码。 这些 HTML 代码或者定义 Web 网页格式，或者引入 Web 浏览器可执行代码段。 Web 服务 器可以使用Cookies 信息创建动态网页。假使 Cookies 包含可执行恶意代码段，那么在显示合成有该 Cookies 的网页时，就会自动执行这段恶意代码。当然，恶意代码能否真正造成危害，还取决于Web 站点的安全配置策略。

会话定置

会话定置(Session Fixation)攻击是指，攻击者向受害者主机注入自己控制的认证Cookie等信息，使得受害者以攻击者的身份登录网站，从而窃取受害者的会话信息。注入Cookie的方法包括：使用跨站脚本或木马等恶意程序；或伪造与合法网站同域的站点，并利用各种方法欺骗用户访问该仿冒网站，从而通过HTTP响应中的Set-Cookie头将攻击者拥有的该域Cookie发送给用户等。

CSRF攻击

跨站请求伪造（Cross-Site Request Forgery，简称CSRF）是指，攻击者可能利用网页中的恶意代码强迫受害者浏览器向被攻击的Web站点发送伪造的请求，篡夺受害者的认证Cookie等身份信息，从而假冒受害者对目标站点执行指定的操作。Firefox、Opera等浏览器使用单进程机制，多个窗口或标签使用同一个进程，共享Cookie等会话数据。IE则混合使用单进程与多进程模式，一个窗口中的多个标签，以及使用“CTRL+N” 或单击网页中的链接打开的新窗口使用同一进程，共享会话数据；只有直接运行IE可执行程序打开窗口时，才会创建新的进程。Chrome虽然使用多进程机制，然而经测试发现，其不同的窗口或标签之间仍会共享会话数据，除非使用隐身访问方式。因而，用户同时打开多个浏览器窗口或标签访问互联网资源时，就为CSRF攻击篡夺用户的会话Cookie创造了条件。另外，如果一个Web站点提供持久化Cookie，则CSRF攻击将更直接、更容易。

安全防护

Web服务器端防护

通过Cookie在客户端与服务器端进行交互，最终实现对用户身份的认证，Cookie成了用户整个身份的代替，其安全性决定了整个系统的安全性，Cookie的安全性问题主要有以下几方面:（1）Cookie被用户非法篡改，如篡改其中的expire项，可将Cookie的有效期延长；篡改path项可使用户能够访问服务器上不被授权的内容；或修改domain项，使用户能够访问不被授权的服务器从而获得合法用户的信息等;（2）被非法用户非法截获，然后在有限期内重放，则非法用户将享有合法用户的合法权益，可能会损害网站方的利益;（3）若Cookie被服务器加密，而非法用户通过强力攻击或其他手段获得了相应的加密密钥，则非法用户可以伪造任何合法Cookie，从而可以访问合法用户的所有个性化信息，甚至是账户信息等。
面对诸如此类的攻击手段，有必要从服务器端对Cookie进行安全设计，保护措施主要有:（1 ）加入MAC以进行完整性校验;（2）防止非法用户非法截获后的重放，可以让用户对相关信息进行数字签名，加强有效性验证;（3）对Cookie本身进行随机密钥加密，保证Cookie本身的信息安全。

客户端浏览器防护

客户端浏览器为了保证本地的Cookie安全，采取了对不同访问网站的统一Cookie加密，在相应的系统目录下，只可看见一个与Cookie相关的加密文件，而且其中的Cookie文件，已被浏览器加密，用户不可见，在用户访问特定站点的时候，可由浏览器对cookies文件进行调用并进行解密，将特定站点的Cookie发送到指定的站点服务器中，实现对用户的Cookie的认证。

主机的安全防护

在原有的服务器端以及客户端对Cookie的安全性控制下，鉴于不同的客户端浏览器对站点的Cookie控制相互独立，可以采取在客户端浏览器对产生的Cookie文件进行基于主机特征的安全性认证，即在浏览器产生Cookie加密文件时，在Cookie文件中加入一段主机的特征，生成一个双层加密的新的Cookie文件；在调用Cookie的时候，通过对Cookie文件进行主机特征的匹配，选择对内层的文件进行解密调用。
然后，对嵌套了主机序列号的内层密文进行二次加密；内层加密保证对源Cookie内容的加密，保证Cookie信息的不可见，外层加密保证对主机特征的保护，以避免对主机特征的替换，通过对Cookie加入主机特征，以及两次对Cookie加密，可以在原有的防护机制下，为Cookie提供更加安全的保护。

认证机制

在 Web认证中 ,因为HTTP协议本身的局限，必须采用其他技术将相关认证标记以某种方式持续传送，以免客户从一个页面跳转至另一个页面时重新输入认证信息。基于Cookie的认证过程，主要由以下三个阶段组成：
（1）发布Cookie。当用户试图访问某Web站点中需要认证的资源时，Web服务器会检查用户是否提供了认证Cookie，如果没有，则将用户重定向到登录页面。在用户成功登录后，Web服务器会产生认证Cookie，并通过HTTP响应中的Set-Cookie头发送给客户端，用于对用户随后的请求进行检查和验证，接着将用户重定向到初始请求的资源。
（2）检索Cookie。在用户随后的访问请求中，客户端浏览器检索Path和Domain等属性与用户请求资源相匹配的Cookie，并将找到的Cookie通过HTTP请求中的Cookie头提交给Web服务器。
（3）验证CookieWeb服务器提取客户端浏览器递交的Cookie，验证其中的访问令牌。若合法，则将访问请求的资源发送给客户端浏览器；反之则拒绝用户的访问请求。Cookie 认证技术简化了用户访问 Web 网站资源的过程，即用户只需在初次登录网站时输入身份信息进行认证，随后便可以访问被授权的所有站点资源，不再需要重复手工提交身份信息。

实例

由于Cookies是我们浏览的网站传输到用户计算机硬盘中的文本文件或内存中的数据，因此它在硬盘中存放的位置与使用的操作系统和浏览器密切相关。在Windows 9X系统计算机中，Cookies文件的存放位置为C:\Windows\Cookies，在Windows NT/2000/XP的计算机中，Cookies文件的存放位置为C:\Documentsand Settings\用户名\Cookies。硬盘中的Cookies文件可以被Web浏览器读取，它的命令格式为：用户名@网站地址[数字].txt。 要注意的是：硬盘中的Cookies属于文本文件，不是程序。

设置

可以在IE的“工具/Internet选项”的“常规”选项卡中，选择“设置/ 查看文件”，查看所有保存到电脑里Cookies。这些文件通常是以user@domain格式命名的，user是本地用户名，domain是所访问的网站的域名。如果使用NetsCape浏览器，则存放在“C:\PROGRAMFILES\NETSCAPE\USERS\”里面，与IE不同的是，NETSCAPE是使用一个Cookie文件记录所有网站的Cookies。可对Cookie进行适当设置：打开“工具/Internet选项”中的“隐私”选项卡（注意该设置只在IE6.0中存在，其他版本IE可以单击“工具/Internet选项”|“安全”标签中的“自定义级别”按钮，进行简单调整），调整Cookie的安全级别。通常情况，可以调整到“中高”或者“高”的位置。多数的论坛站点需要使用Cookie信息，如果从来不去这些地方，可以将安全级调到“阻止所有Cookies”；如果只是为了禁止个别网站的Cookie，可以单击“编辑”按钮，将要屏蔽的网站添加到列表中。在“高级”按钮选项中，可以对第一方Cookie和第三方的Cookie进行设置，第一方Cookie是正在浏览的网站的Cookie，第三方Cookie是非正在浏览的网站发送的Cookie ，通常要对第三方Cookie选择“拒绝”。如果需要保存Cookie，可以使用IE的“导入导出”功能，打开“文件/导入导出”，按提示操作即可。

写入与读取

Cookies集合是附属于Response对象及Request对象的数据集合，使用时需要在前面加上Response或Request。用于给客户机发送Cookies的语法通常为：

< %Response.cookies(“Cookies名称”)=数据% > 

当给不存在的Cookies集合设置时，就会在客户机创建，如果该Cookies己存在，则会被代替。由于Cookies 是作为HTTP传输的头信息的一部分发给客户机的，所以向客户机发送Cookies的代码一般放在发送给浏览器的HTML 文件的标记之前。如果用户要读取Cookies，则必须使用Request对象的Cookies集合，其使用方法是：

< %efg=request.cookies(“abc”) (将cookies对象abc的值赋给efg)% > 

需要注意的是，只有在服务器未被下载任何数据给浏览器前，浏览器才能与Server进行Cookies集合的数据交换，一旦浏览器开始接收Server所下载的数据，Cookies的数据交换则停止，为了避免错误，要在程序和前面加上response.Buffer=True。