每日分享
Wherever you go, go with all your heart.
既来之，则安之。（字面意思是无论你去哪里，请全心全意的去。）
小闫语录：
既来之，则安之。看似是一种无奈，一种妥协，其实却是智慧之举。我们既然已经来到这个地方，既然已经做了这份工作，那么就全心全意的去对待。我们要保持着积极向上的态度，即使枯燥的工作，我们任然可以学习收获很多。你要相信，没有任何一件事是白做的，你所学的东西，总会在以后的某一刻使用到。少一些功利心，少一些消极态度，会发现生活如此美好。
美多商城前三天遗忘知识点回顾
项目的远程仓库地址
https://github.com/EthanYan6/E-commerce-sites.git
在readme中有目录结构的解释：
E-commerce-sites
├── Ethanyan_mall
│ ├── celery_tasks
│ ├── docs(用于存放一些说明文档资料)
│ ├── Ethanyan_mall
│ │ ├── apps(存放Django的应用)
│ │ ├── __init__.py
│ │ ├── libs(存放第三方的库文件)
│ │ ├── settings(存放配置文件的目录，分为开发dev和线上prod)
│ │ ├── urls.py(存放项目自己定义的公共函数或类等)
│ │ ├── utils(存放项目自己定义的公共函数或类等)
│ │ └── wsgi.py
│ ├── __init__.py
│ ├── logs(日志文件)
│ ├── manage.py(启动文件)
│ └── scripts(用于存放管理脚本文件)
├── front_end_pc(静态文件)
├── LICENSE
├── note
└── README.md
1.修改配置文件中项目路径
我们将Django的应用放到了 工程目录/Ethanyan_mall/apps目录下，如果创建一个应用，比如users，那么在配置文件的INSTALLED_APPS中注册应用应该如下：
INSTALLED_APPS = [
...
'Ethanyan_mall.apps.users.apps.UsersConfig',
]
为了还能像如下方式简便的注册引用，我们需要向Python解释器的导包路径中添加apps应用目录的路径。
INSTALLED_APPS = [
...
'users.apps.UsersConfig',
]
我们将配置文件改为放在settings子目录下，所以 配置文件中的 BASE_DIR指向的变为了 E-commerce-sites/Ethanyan_mall/Ethanyan_mall。
使用 sys.path添加 <BASE_DIR>/apps目录，即可添加apps应用的导包路径。
# Build paths inside the project like this: os.path.join(BASE_DIR, ...)
BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
# 添加导包路径
import sys
sys.path.insert(0, os.path.join(BASE_DIR, 'apps'))
2.分布式
在前面介绍session认证机制存在的问题时，有一点『对于分布式网站应用中，如果session存储在内存中，session共享会产生问题』也许大家已经忘记了。
1.为什么session共享会产生问题？
答：在网站部署的时候，有很多服务器运行着，某台服务器内存中存着一位用户的session，其他服务器中是没有的。如下次该用户发起请求，Nginx在转发的时候，有可能交给了其他的服务器处理，那么该用户的session就不存在了，相对应的，用户的一些信息也就没有了，用户体验会下降。这就是session共享产生的问题。
2.如果不将session存储在内存中还能存储在哪里？
答：我们在美多商城项目中使用的JWT认证机制解决了session认证机制的问题，如果是要使用session认证机制其实也是可以解决的，就是我们要了解的分布式缓存了。大型网站的数据量是相当庞大的，就是只缓存其中一部分，那么需要的内存也是远远超乎我们的想象的。就好比10的百分之一是0.1，1000000的百分之一就是10000。这么大的内存单机怎么可能承受的了？所以我们除了本地缓存，还需要分布式缓存，也就是将数据缓存到一个专门的分布式缓存集群中，应用程序通过网络通信访问缓存数据。
3.token类型
在前面介绍jwt token字符串格式的时候，header中包含了token的类型，那么token的类型包括哪些呢？
答：我们在jwt中的token类型当然就是『JWT』了，除此之外还有防止CSRF攻击时使用的『csrftoken』，以及我们在使用第三方QQ登录的时候，获取加密的openid内容使用到的『accesstoken』。具体的类型，分类因为没有查到相关内容，不是很清楚，小编只是将之前碰到的token进行一个汇总，如果有不恰当的地方，大家多多谅解。
4.JWT
1.JWT使用的过程中服务器端保存了什么，客户端保存了什么？
答：服务器端保存的是SECRET私钥；客户端保存的是服务器加密后的jwt token。
2.JWT的校验过程？
答：客户端发起请求的时候，传递给服务器一个jwt token，jwt token分为三部分：头部(header)、载荷(payload)和签证(signature)。服务器在收到这个token的时候将前两部分header和payload使用header中的加密算法HMACSHA256进行加盐SECRET组合加密，然后将生成的签名信息与jwt token中的第三部分signature进行对比，如果一致，说明token合法，否则就是伪造的。因为生成签名信息的SECRET只有服务器知道，所以相对来说很安全。
3.JWT中是如何加密的，安全吗？
答：JWT中header、payload都是由base64加密的，而base64是对称加密解密的过程，不安全，详细内容介绍见5。signature部分则是将上面加密过的头部和载荷利用头部中声明的加密方式(HMACSHA256)进行加盐 secret组合加密，这样一来三部分组合而成的JWT就相对安全了。因为万事没有绝对，只能是相对的安全。
注意：secret是保存在服务器端的，jwt的签发生成也是在服务器端的，secret就是用来进行jwt的签发和jwt的验证，所以，它就是你服务端的私钥，在任何场景都不应该流露出去。一旦客户端得知这个secret, 那就意味着客户端是可以自我签发jwt了。
4.token中可以存放敏感的信息吗？
答：不可以，前面已经提到了，token的header和payload是经过base64加密的，而base64是对称加密，并不安全，因此不建议存放敏感信息。
5.对称加密和非对称加密
5.1对称加密解密
在对称加密的过程中，只有一个秘钥，无论是加密还是解密，都是这一个秘钥。可想而知，如果是秘钥丢失，那么就相当于明文了。因此对称加密使用的秘钥的安全性相当重要，一定不能公开。
5.2非对称加密解密
在非对称加密的过程中，有一对秘钥(公钥和私钥)，公钥是对外公开的，任何一个客户端都可以有，但是私钥有且只有一个。服务器保存公钥和唯一的私钥，客户端的公钥由服务器传递。特点是公钥和私钥都可以进行加密，但是公钥加密的密文只有私钥能够解密，私钥加密的密文所有公钥都可以进行解密，这就是非对称加密。但是也有缺点，问题就出现在server给client发送消息的时候就不安全，因为所有的公钥都可以解密。要想解决，使用HTTPS协议就可以了。
6.QQ登录开发流程
6.1QQ登录开发流程中涉及到的参数
| 参数 | 说明 |
|---|---|
| code | QQ返回的授权凭证，根据code可以获取access_token |
| access_token | 用户是第一次使用QQ登录时返回，其中包含openid，用于绑定身份使用，注意这个是我们自己生成的。 |
| token | 用户不是第一次使用QQ登录时返回，登录成功的JWT token |
| status | client端的状态值。用于第三方应用防止CSRF攻击，成功授权后回调时会原样带回。请务必严格按照流程检查用户与state参数状态的绑定。重定向到我们指定的页面，如果用户没有进行绑定，会跳转绑定的页面，这个时候在查询字符串中有两个参数，一个是code，一个是status |
| openid | OpenID是此网站上或应用中唯一对应用户身份的标识，网站或应用可将此ID进行存储，便于用户下次登录时辨识其身份，或将其与用户在网站上或应用中的原有账号进行绑定。 |
6.2QQ登录开发流程
1.客户端向服务器发出请求，获取QQ登录的网址。
2.服务器向客户端返回QQ登录网址和参数。
给客户端返回的数据json格式：
{
"login_url": "https://graph.qq.com/oauth2.0/show?which=Login&display=pc&response_type=code&client_id=101474184&redirect_uri=http%3A%2F%2Fwww.meiduo.site%3A8080%2Foauth_callback.html&state=%2F&scope=get_user_info"
}
3.客户端根据返回的QQ登录网址向QQ服务器发起请求。
4.QQ服务器向客户端返回QQ授权登录页面。
5.用户在授权页面进行QQ登录。
6.QQ服务器会让客户端跳转到指定的回调网址，并在重定向的网址后面带上code和原始的state值。此处的参数是QQ服务器提供的。
7.客户端访问回调网址，携带QQ提供的code参数给服务器。然后获取QQ登录用户的openid并处理。
8.服务器根据code请求QQ服务器获取access_token。
9.QQ服务器向服务器返回所需要的access_token。
10.服务器凭借access_token请求QQ服务器获取openid。
11.QQ服务器返回openid给服务器。
12.服务器接下来根据openid判断是否绑定过本网站用户。后端接口根据openid到数据库查询tboatuqq表(该表中记录了openid和User_id的绑定情况)
13.如果绑定过，直接签发jwt token并返回给客户端，让客户端保存这个token。
14.如果没有绑定过，将openid加密并返回给客户端。
15.前端也会做相应的判断，如果绑定过，直接就返回到首页登录网址，如果没有绑定过，则会在浏览器显示绑定页面，要求用户填写表单进行绑定。
16.用户在填写完上面的表单，点击保存按钮的时候，客户端想服务器发起请求绑定QQ登录用户，服务器将表单信息保存到数据库中。
17.服务器签发jwt token并返回给客户端。
优质文章推荐:
1828
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
