【微信、单点】
-
-
- 1.OAuth2的作用？
- 2.网站使用微信登录需要做什么？
- 3.认证流程：
- 4.参数说明？
- 5.获取 access_token 后可以进行哪些操作？
- 6.redirect_uri 的作用分析，以及如何防止黑客篡改redirect_uri ？
- 7.appsecret 的作用是什么？为什不能在第一步就发送appsecret呢？
- 8.code的作用是什么？为什么要在第四步先返回一个code呢，而不是直接返回 accsess_token 呢？（暴露，appsecret）
- 9.state字段的作用？
- 10.拿到 access_token 后，第三方应用 在后续的请求里，access_token 还是直接发送给 认证服务器 的，这个时候就不能截取了吗？
- 11.什么是Token?
- 12.refresh_token的过期时间可以在哪里设置？后端拿到解析的时候
- 13.Token可以存放在哪里？
- 14.JWT的组成？
- 15.JWT的用途？
- 16.什么是单点登录Single Sign On（SSO）？
- 17.单系统是如何登录的？
- 18.多系统是如何实现单点登录的？
- 19.多系统登录带来的问题？
- 20.CSRF攻击是什么？
- 21.如何防御CSRF攻击？
- 22.什么是XSS攻击？
- 25.什么是Session?
- 26.Cookie、Session认证流程
- 27.Cookie和Session的区别？
- 29.什么是跨域？
- 30.怎么解决跨域问题？
- 32.为什么要有同源策略？
- 33.HTTP请求方式有几种？
-
1.OAuth2的作用？
微信 OAuth2.0 授权登录让微信用户使用微信身份安全登录第三方网站，第三方可以获取到用户的接口调用凭证（access_token），通过 access_token 可以获取微信用户基本开放信息和帮助用户实现基础开放功能。
特点：简单，安全，开放
4种模式：
授权码模式：安全性最高。
密码模式：如果高度信任某个应用，RFC 6749 也允许用户把用户名和密码，直接告诉该应用。该应用就使用你的密码，申请令牌。（比如自家搭建的授权服务器），流程如下：
（A）用户向客户端提供用户名和密码。
（B）客户端将用户名和密码发给授权服务器，向后者请求令牌。
（C）授权服务器确认无误后，向客户端提供访问令牌。
简化(隐式)模式：应用于纯前端应用，没有“授权码”这个步骤，直接向前端颁发令牌。这种方法很不安全的。
客户端模式：指客户端以自己的名义，而不是以用户的名义，向"服务提供商"进行授权。适用于没有前端的命令行应用，即在命令行下请求令牌
2.网站使用微信登录需要做什么？
如果一个网站要使用微信登录，必然是要去微信公众号后台申请 appid，并且在申请的时候，还要填写一个获取 code的域名，而微信后台也会给一个 appsecret 。
3.认证流程：
(1)微信用户请求登录第三方应用；
(2)第三方应用携带 appid 以及 redirect_uri 通过重定向的方式请求微信OAuth2.0授权登录，微信开放平台请求用户确认登录。
①注意：这一步没有发送appsecret；
②注意：此时微信开放平台是无法确定第三方应用身份的，因为这时微信开放平台只有一个appid，没有任何手段来确认 第三方应用使用的是自己的 appid；
(3)微信用户扫码认证（在 微信开放平台 上认证身份），并统一授权给 第三方应用；
(4)授权后，微信 会 302 跳转到 第三方网站 的 redirect_uri 上，并且带上授权临时票据 code（也就是 authorization code）和state；
①比如：http://test.com/test/pay?code=CODE&state=STATE
②注意：按 OAuth2.0 的协议约定，该 code 通过浏览器的 302 重定向发送给 第三方应用，这意味着 code 值从浏览器就能看到了，非常危险。
(5)第三方应用 拿 code 以及 appid、appsecret 换取 accsess_token 和 openid；
①注意：这个过程是 第三方应用 后台 对 微信开放平台 后台 的，不依赖浏览器，所以access_token不会像 code 那样会暴露出去。
②并且第三方应用 需要提供自己的 appsecret，这样就为 微信开放平台 提供了一种验证 第三方应用 的机制。
4.参数说明？
5.获取 access_token 后可以进行哪些操作？
(1)获取用户个人信息：
①开发者可通过 OpenID 来获取用户基本信息；
②如果开发者拥有多个移动应用、网站应用和公众帐号，可通过获取用户基本信息中的 unionid 来区分用户的唯一性，因为只要是同一个微信开放平台帐号下的移动应用、网站应用和公众帐号，用户的 unionid 是唯一的；而OpenId（UnionId） 是用户和应用程序(应用 程序所有者)共同生成的唯一ID；
③请求：
GET https://api.weixin.qq.com/sns/userinfo?access_token=ACCESS_TOKEN&openid=OPENID
(2)刷新或续期 access_token 使用：
①access_token 是调用授权关系接口的调用凭证，由于 access_token 有效期（目前为 2 个小时）较短，当 access_token 超时后，可以使用 refresh_token 进行刷新，access_token 刷新结果有两种：
1)若 access_token 已超时，那么进行 refresh_token 会获取一个新的 access_token，新的超时时间；
2)若 access_token 未超时，那么进行 refresh_token 不会改变 access_token，但超时时间会刷新，相当于续期 access_token。
②refresh_token 拥有较长的有效期（30 天）且无法续期，当 refresh_token 失效的后，需要用户重新授权后才可以继续获取用户头像昵称。
③请求：
GET https://api.weixin.qq.com/sns/oauth2/refresh_token?appid=APPID&grant_type=refresh_token&refresh_token=REFRESH_TOKEN
(3)检验授权凭证（access_token）是否有效
6.redirect_uri 的作用分析，以及如何防止黑客篡改redirect_uri ？
微信登录开发的过程中，获取 code 一步，如果给微信服务器传的 redirect_uri 参数值不是申请 appid 时所输入的域名，那么微信会立马返回『redirect_uri 参数错误』的提示。
案例：如果不进行验证，这时候有攻击者改变了uri，那么微信登录平台就把code传给了攻击者网站，然后攻击者网站再把code返回到第三方网站，那么攻击者就能以受害者身份登录网站。
也能解决：因为code只能使用一次，若是攻击者比正常用户先用了 code 也没事，因为如果同一个 code 被用了两次，之前通过此 code 获取的access token 将被撤回，而普通用户本来就是要访问拿 code 换 access token 的地址，code 是一定会被用的。
当进行调试时，直接将uri的域名通过hosts文件直接指向内网（127.0.0.1）就行了。
7.appsecret 的作用是什么？为什不能在第一步就发送appsecret呢？
Appsecret就相当于第三方网站的密码，通过申请时获得的appid和appsecret去身份认证服务器进行验证。
第一步是通过redirect重定向方式将appid,redirect_uri发送到微信认证服务器，是非常不安全的，因为我们可以在浏览器看到。而获取token那一步是第三方网站服务器内部发起的，用户不可见，所以安全。
8.code的作用是什么？为什么要在第四步先返回一个code呢，而不是直接返回 accsess_token 呢？（暴露，appsecret）
code 是通过浏览器重定向获取的，你在浏览器地址栏就可以看到，如果这一步不返回code而是直接返回 access token，那么这个token其实已经暴露了；而 第三方应用 拿到 code 以后换取 access_token 和 openid 是 第三方应用后台 对 认证服务器的访问，不依赖浏览器，access token不会暴露出去。
并且如果我们直接返回access_token，那么在第一步就需要将 appsecret 提供给微信认证服务器。
9.state字段的作用？
(1)state 参数是为了保证申请 code 的设备和使用 code 的 设备的一致 而存在的。
(2)当state参数为0,作为攻击者:
①先申请一个新的，专门用于攻击他人的账号；
②然后走正常流程，跳到微信上去登录此账号；
③登录成功之后，微信带着 code 回跳到 test.com，这个时候，攻击者拦截自己的请求让他不再往下进行，而直接将带 code 的链接发给受害者，并欺骗受害者点击；
④受害人点击链接之后，继续攻击者账号的登录流程，不知不觉登录了攻击者的账号(如果上传了一些私人照片后攻击者就能通过账号看到)。
(3)而这时候如果微信带着code和state一起回跳的时候，服务器（比如 test.com）分配给受害者的设备的 state 值 和 链接里面的（分配给攻击者的）state 值不一样，服务器（test.com）直接返回验证 state 失败.
注意：state 或者说 CSRF Token 这种跟设备绑定的随机字符串，只要稍微复杂一点，攻击者根本就不可能猜得出来，而设置一个让攻击者猜不到的，跟设备或者说浏览器绑定的 state （CSRF token 同理） 值，就是解决 CSRF 攻击的关键。
10.拿到 access_token 后，第三方应用 在后续的请求里，access_token 还是直接发送给 认证服务器 的，这个时候就不能截取了吗？
这里其实是 通过 HTTPS 保证安全性的，虽然 OAuth2.0 协议没有明文要求 OAuth 认证服务的厂家 使用 HTTPS ，但实际上 OAuth 认证服务的厂家 提供的接口都是 HTTPS 的。
11.什么是Token?
一般是用户通过用户名和密码登录成功之后，服务器将登陆凭证作为数字签名，加密之后得到的字符就是token，简单来说就是对身份进行验证。
12.refresh_token的过期时间可以在哪里设置？后端拿到解析的时候
13.Token可以存放在哪里？
①、cookie：每次调用接口会自动发送，不过缺点是不能跨域。可以指定httponly，来防止被javascript读取，也可以指定secure ，来保证token只在HTTPS下传输。 并且容易遭受CSRF攻击。
②、localStorage：局部存储器。它是html5新增的一个本地存储API，存储在浏览器中。每次调用接口时放在http请求头里面，长期有效。
优点：生命周期是永久，除非用户显示在浏览器提供的UI上清除localStorage信息，否则这些信息将永远存在。相同浏览器的不同页面间可以共享相同的localStorage (页面属中相可域名和端口)。
缺点：同一个属性名的数据会被替换，不同浏览器无法共享localStorage或sessionStorage中的信息。
③、sessionStorage ：是HTML5新增的一个会话存储对象，用于临时保存同一窗口(或标签页)的数据，每次调用接口时，把它当为一个字段传给后台，浏览器关闭自动清除
优点： 命周期为当前窗口或标签页，sessionStorage的数据不会被其他窗口清除，页面及标签页仅指顶级窗口，如果一个标签页包含多个iframe标签且他们属于同源页面，那么他们之间是可以共享sessionStorage的。
缺点：一旦窗口或标签页被永久关闭了，那么所有通过sessionStorage存储的数据也就被清空了。
14.JWT的组成？
一个JWT实际上就是一个字符串，它由三部分组成，头部（header）（存储签名所用的算法等）、载荷（payload）（存放有效的信息）与签名 （signature）（签证信息）。
JWT令牌的优点：
- jwt基于json，非常方便解析。
- 可以在令牌中自定义丰富的内容，易扩展。
- 通过非对称加密算法及数字签名技术，JWT防止篡改，安全性高。
- 资源服务使用JWT可不依赖授权服务即可完成授权。
缺点：JWT令牌较长，占存储空间比较大。
15.JWT的用途？
(1)通过JWT，设置一些用信息户，创建日期，签名手段，过期时间，刷新有效时间（refresh_token）等来创建token。
16.什么是单点登录Single Sign On（SSO）？
(1)单点登录就是在多个系统中，用户只需一次登录，各个系统即可感知该用户已经登录。比如阿里系的淘宝和天猫，虽然是两个系统，但只要登录一次就好了。
(2)为什么要分成多个系统？在以前的时候，一般我们的系统都是单系统，也就是说所有的功能都在同一个系统上。比如订单功能，登录功能等。后来，为了合理利用资源和降低耦合性，于是把单系统拆分成多个子系统。
17.单系统是如何登录的？
①用户第一次请求服务器的时候，服务器根据用户提交的相关信息，创建对应的 Session；
②请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器（放到set-cookie种）；
③浏览器接收到服务器返回的 SessionID 信息后，会将此信息存入到 Cookie 中，同时 Cookie 记录此 SessionID 属于哪个域名；
④当用户第二次访问服务器的时候，请求会自动判断此域名下是否存在 Cookie 信息;
⑤如果存在自动将 Cookie 信息也发送给服务端，服务端会从 Cookie 中获取 SessionID，再根据 SessionID 查找对应的 Session 信息；
1)如果没有找到说明用户没有登录或者登录失效，如果找到 Session 证明用户已经登录可执行后面操作。
⑥此时，当我们在该网站的不同的网页中左右横跳的时候，通过跟随request中的cookie中的 sessionID ，使用相同的session。
⑦当过了一段时间后，服务器中对应的session的生命周期过去，session中的内容写入数据库，该session被清除。
⑧当再访问页面时，会使用cookie重新登录，服务器重新创建session，重复过程。
18.多系统是如何实现单点登录的？
我们把Session数据放在Redis中，实现Session共享，并通过设置domain解决cookie跨域问题 。并且将 将登录功能单独抽取出来做成一个子系统。
(1)用户登录流程：
①根据 用户名 和 密码 去数据库进行查询；
1)首先用用户名查询，如果未查询到则说明用户不存在；如果用户存在，则进行密码核对，如果密码正确则登录成功。
②判断登录成功之后，生成一个Token，然后将这个token存入redis，并设置过期时间（这里Token其实就是一个UUID）。
1)用户登录其他子系统时，其它子系统会请求 SSO（登录系统）中的登录方法进行登录流程（也就是上面的逻辑），将返回的token写到Cookie中，下次访问时HTTP请求会自动把Cookie带上。
③之后用户每次发起HTTP请求时，都会自动将Cookie都会带上，后端可以通过拦截器得到token，进而判断该用户是否已经登录。
方法二：也可以基于网关层进行实现，网关在认证授权体系里主要负责两件事：
（1）作为OAuth2.0的资源服务器角色，实现接入方权限拦截（implements GlobalFilter, InitializingBean进行实现）。
（2）令牌解析并转发当前登录用户信息（明文token）给微服务
19.多系统登录带来的问题？
①Session不共享问题：单系统登录功能主要是用Session保存用户信息来实现的，但我们清楚的是：多系统即可能有多个Tomcat，而Session是依赖当前系统的Tomcat，所以系统A的Session和系统B的Session是不共享的。
1)Session不共享的解决方法：
a.Tomcat集群Session全局复制（集群内每个tomcat的session完全同步）【会影响集群的性能呢，不建议】
b.根据请求的IP进行Hash映射到对应的机器上（这就相当于请求的IP一直会访问同一个服务器）【如果服务器宕机了，会丢失了一大部分Session的数据，不建议】
c.把Session数据放在Redis中（使用Redis模拟Session）【建议】
②Cookie跨域的问题：Cookie是不能跨域的。，比如由于域名不同，用户向系统A登录后，系统A返回给浏览器的Cookie，用户再请求系统B的时候不会将系统A的Cookie带过去。
1)解决方案：
a.服务端将Cookie写到客户端后，客户端对Cookie进行解析，将Token解析出来，此后请求都把这个Token带上就行了；
b.多个域名共享Cookie，在写到客户端的时候设置Cookie的domain；
c.将Token保存在SessionStroage中（不依赖Cookie就没有跨域的问题了）。
20.CSRF攻击是什么？
CSRF：跨站点请求伪造
攻击者盗用了用户的身份，以用户的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以用户的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等。
举例：
A为存在CSRF漏洞的网站，B为攻击者构建的恶意网站，C为Web A网站的合法用户。
第一步：用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A；
第二步：在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A；
第三步：用户未退出网站A之前，在同一浏览器中，打开一个TAB页 访问 网站B；
第四步：网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A；
第五步：浏览器在接收到这些攻击性代码后：
①、用户相当于无意中在自己的 浏览器 上执行了网站B返回的攻击代码中的http请求，在用户不知情的情况下携带Cookie信息，向网站A发出请求；
②、网站A并不知道该请求其实是由B发起的，所以会根据用户C的Cookie信息以C的权限处理该请求，导致来自网站B的恶意代码被执行。
21.如何防御CSRF攻击？
主要有三种策略：
(1)验证 HTTP Referer 字段：
①在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地址。通常情况下，访问一个安全受限页面的请求来自于同一个网站，比如银行转账，该转帐请求的 Referer 值就会是转账按钮所在的页面的 URL，而如果黑客要对银行网站实施 CSRF 攻击，他只能在他自己的网站构造请求，当用户通过黑客的网站发送请求到银行时，该请求的 Referer 是指向黑客自己的网站。因此，要防御 CSRF 攻击，银行网站 只需要对于每一个转账请求验证其 Referer 值：
如果Referer是其他网站，就取决该请求。
②优点：简单易行，网站的普通开发人员不需要操心 CSRF 的漏洞，只需要在最后给所有安全敏感的请求统一增加一个拦截器来检查 Referer 的值就可以。
③缺点：对于一些浏览器，黑客可以修改用户浏览器的Referer值，其次Referer值记录用户的访问来源，有些用户会认为其侵犯隐私了，因此，用户自己可以设置浏览器使其在发送请求时不再提供 Referer。当他们正常访问银行网站时，网站会因为请求没有 Referer 值而误认为是 CSRF 攻击，拒绝合法用户的访问。
(2)在请求地址中添加 CSRF Token 并验证：
CSRF 攻击之所以能够成功，是因为黑客可以完全伪造用户的请求，该请求中所有的用户验证信息都是存在于 cookie 中，因此黑客可以在不知道这些验证信息的情况下直接利用用户自己的 cookie 来通过安全验证。
要抵御 CSRF，关键在于在请求中放入黑客所不能伪造的信息，并且该信息不存在于 cookie 之中。
可以在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。
①对于GET请求，token 将附在请求地址之后，对于POST请求，要在form的最后加上 ，这样就把 token 以参数的形式加入请求了。
②缺点：
1)对于每一个请求都加上 token 是很麻烦的，并且很容易漏掉。
a.通常使用的方法就是在每次页面加载时，使用 javascript 遍历整个 dom 树，对于 dom 中所有的 a 和 form 标签后加入 token。这样可以解决大部分的请求，但是对于在页面加载之后动态生成的 html 代码，这种方法就没有作用，需要程序员在编码时手动添加 token。
b.该方法还有一个缺点是 难以保证 token 本身的安全。特别是在一些论坛之类支持用户自己发表内容的网站，黑客可以在上面发布自己个人网站的地址。由于系统也会在这个地址后面加上 token，黑客可以在自己的网站上得到这个 token，并马上就可以发动 CSRF 攻击。为了避免这一点，系统可以在添加 token 的时候增加一个判断：
a)如果这个链接是链到自己本站的，就在后面添加 token，如果是通向外网则不加；
b)不过，即使这个 csrf token 不以参数的形式附加在请求之中，黑客的网站也同样可以通过 Referer 来得到这个 token 值 以发动 CSRF 攻击。这也是一些用户喜欢手动关闭浏览器 Referer 功能的原因。
(3)在 HTTP 头中自定义属性并验证：
①这种方法也是使用 token 并进行验证，把它放到 HTTP 头中自定义的属性里。
1)通过 XMLHttpRequest 这个类，可以一次性给所有该类请求加上 csrftoken 这个 HTTP 头属性，并把 token 值放入其中。
2)同时，通过 XMLHttpRequest 请求的地址不会被记录到浏览器的地址栏，也不用担心 token 会透过 Referer 泄露到其他网站中去。
②局限性：
1)XMLHttpRequest 请求 通常用于 Ajax 方法中对于页面局部的异步刷新，并非所有的请求都适合用这个类来发起；-
2)而且 通过该类请求得到的页面不能被浏览器所记录下，从而进行前进，后退，刷新，收藏等操作，给用户带来不便；
3)另外，对于没有进行 CSRF 防护的遗留系统来说，要采用这种方法来进行防护，要 把所有请求都改为 XMLHttpRequest 请求，这样几乎是要重写整个网站，这代价无疑是不能接受的。
(4)CSRF漏洞检查？
①检测CSRF漏洞是一项比较繁琐的工作，最简单的方法就是抓取一个正常请求的数据包，去 掉Referer字段后再重新提交，如果该提交还有效，那么基本上可以确定存在CSRF漏洞。
②检测工具：CSRFTester。
1)原理：首先需要抓取我们在浏览器中访问过的所有链接以及所有的表单等信息，然后通过在CSRFTester中修改相应的表单等信息，重新提交，这相当于一次伪造客户端请求。如果修改后的测试请求成功被网站服务器接受，则说明存在CSRF漏洞，当然此款工具也可以被用来进行CSRF攻击。
22.什么是XSS攻击？
(1)跨站脚本攻击（前端注入） ，用户输入的数据当做前端代码执行。 设置 cookie 操纵浏览器：
(2)盗取cookie并发送，获取内网 ip （攻击内网、扫描内网）
23.为什么要用Cookie和Session?
(1)HTTP 是无状态的协议,每个HTTP请求都是完全独立的，服务端无法确认当前访问者的身份信息，无法分辨上一次的请求发送者和这一次的发送者是不是同一个人。所以服务器与浏览器为了进行会话跟踪，就必须主动的去维护一个状态，这个状态用于 告知服务端前后两个请求是否来自同一浏览器 。而这个状态需要通过 cookie 或者 session 去实现。
24.什么是Cookie?
(1)Cookie: 是客户端保存用户信息的一种机制，用来记录用户的一些信息，实际上Cookie是服务器在本地机器上存储的一小段文本，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。
1)cookie 是不可跨域的： 每个 cookie 都会绑定单一的域名，无法在别的域名下获取使用，一级域名和二级域名之间是允许共享使用的（靠的是 domain）。
2)Cookie会根据 HTTP响应报文 里的一个叫做Set-Cookie的首部字段信息，通知客户端保存Cookie。当下客户端再向服务端发起请求时，客户端会自动在请求报文中加入Cookie值之后发送出去。之后服务端发现客户端发送过来的Cookie后，会检查是那个客户端发送过来的请求，然后对服务器上的记录，最后得到了之前的状态信息。
25.什么是Session?
(1)session 是另一种记录服务器和客户端会话状态的机制，是基于 cookie 实现的，session 存储在服务器端，sessionID 会被存储到客户端的 cookie 中。
(2)服务端执行session机制时候会生成 sessionID 值，这个ID值会发送给客户端，客户端每次请求都会把这个ID值放到HTTP请求的头部发送给服务端，而这个id值在客户端会保存下来，保存的容器就是cookie。
26.Cookie、Session认证流程
(1)用户第一次请求服务器的时候，服务器根据用户提交的相关信息，创建对应的 Session；
(2)请求返回时将此 Session 的 唯一标识信息 SessionID 返回给浏览器；
(3)浏览器接收到服务器返回的 SessionID 信息后，会将此信息存入到 Cookie 中，同时 Cookie 记录此 SessionID 属于哪个域名；
(4)当用户第二次访问服务器的时候，请求会自动判断此域名下是否存在 Cookie 信息;
(5)如果存在自动将 Cookie 信息也发送给服务端，服务端会从 Cookie 中获取 SessionID，再根据 SessionID 查找对应的 Session 信息；
(6)如果没有找到说明用户没有登录或者登录失效，如果找到 Session 证明用户已经登录可执行后面操作。
(7)此时，当我们在该网站的不同的网页中左右横跳的时候，通过跟随request中的cookie中的 sessionID ，使用相同的session。
(8)当过了一段时间后，，服务器中对应的session的生命周期过去，session中的内容写入数据库，该session被清除。
(9)此时再访问页面，会使用cookie重新登录，服务器重新创建session，重复上述过程。
27.Cookie和Session的区别？
①安全性： Session 比 Cookie 安全，Session 是存储在服务器端的，Cookie 是存储在客户端的。
②存取值的类型不同：Cookie 只支持存字符串数据，想要设置其他类型的数据，需要将其转换成字符串，Session 可以存任意数据类型。
③有效期不同： Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭（默认情况下）或者 Session 超时都会失效。
④存储大小不同： 单个 Cookie 保存的数据不能超过 3K，Session 可存储数据远高于 Cookie，但是当访问量过多，会占用过多的服务器资源。
28.为什么要解决跨域问题？
现在绝大多数公司的项目都是前后端分离的，前后端分离后势必会遇到跨域问题。
当你和前端联调的时候一直请求失败，报网络错误，一般情况下是后端没有做跨域配置。注意此时并不是后端没有收到请求，而是收到请求了，也返回结果了，但是浏览器将结果拦截了，并且报错。
29.什么是跨域？
(1)当一个请求url的协议、域名、端口三者之间任意一个与当前页面url不同即为跨域。
30.怎么解决跨域问题？
虽然同源策略保证了安全，但一些合理的用途也会受到影响。例如：前端项目在a域名下发送一个Ajax请求到b域名，由于同源策略我们的Ajax请求会报错，导致不能正常请求接口。解决跨域的方式之一：CROS
浏览器将CORS请求分成两类：简单请求（simple request）和非简单请求（预检请求）（not-so-simple request）。
(1)非简单请求：
(2)简单请求：只要满足两个条件，都属于简单请求
①请求方法是以下三种方法之一： HEAD 、GET、 POST
②HTTP请求头信息不超出几种字段：Accept、 Accept-Language、 Content-Language、 Last-Event-ID、 Content-Type：只限于三个值application
简单请求会在请求中加入Origin头，直接发起请求，不会先询问，后端返回相应的header即可。在响应中检查Access-Control-Allow-Origin，不符合要求就报错。
(3)项目中怎么解决跨域问题（基于Spring）
理解了跨域的本质，再看各种配置其实就是根据请求往reponse中增加header。
1)利用Filter:是对javax.servlet.Filter的封装，本质上是一个Filter。会在response上多加上一个header。
2)利用CorsRegisty：添加映射路径
3)利用@CrossOrigin注解：支持更细粒度的配置，可以用法方法上或者类上。
31.什么是同源策略？
(1)同源策略（Sameoriginpolicy）是一种约定，它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，则浏览器的正常功能可能都会受到影响。可以说Web是构建在同源策略基础之上的，浏览器只是针对同源策略的一种实现。
(2)同源策略会阻止一个域的javascript脚本和另外一个域的内容进行交互。所谓同源（即指在同一个域）就是两个页面具有相同的协议（protocol），主机（host）和端口号（port）。
32.为什么要有同源策略？
33.HTTP请求方式有几种？
(1)8种
(2)HTTP/1.1协议中共定义了八种方法（有时也叫“动作”），来表明Request-URL指定的资源不同的操作方式
(3)其中：
①HTTP1.0定义了三种请求方法： GET, POST 和 HEAD方法。
②HTTP1.1新增了五种请求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。
(4)https://blog.csdn.net/weixin_48520816/article/details/125274160