携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第14天，点击查看活动详情

一、单体应用的安全

系统中某些页面只有在正常登录后才可以使用，用户请求这些页面时要检查session中有无该用户信息。

解决方案：编写一个用于检测用户是否登录的过滤器，如果用户未登录，则重定向到指定的登录页面。

二、集群环境下如何解决登陆问题

1、解决方案一

NG的iphash算法：IP绑定 ip_hash每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。

缺点：不能充分考虑到各个服务器的性能,有可能同一时刻访问通过ip_hash出来都请求到一台服务器上，而且这台服务器的性能不行。

2、解决方案二

集中式Session。

三、微服务安全

1、什么是一个Oauth2协议？

你真的没有接触过Oatuh2协议么？不，你肯定接触过。

生活场景：你玩王者农药登陆账号的时候，有一个用QQ登陆的选项，然后你点击该按钮，然后通过QQ登陆进入游戏。

OAuth（开放授权）是一个开放标准，允许用户你授权第三方应用王者农药访问用户存储在另外的服务提供者QQ服务器上的信息，而不需要将用户名和密码提供给第三方移动应用王者农药，这个就是典型的授权码模式。

密码模式使用场景：张三通过浏览器访问"云冲印网站"，去打印你在微信上存储的照片。

问题是只有得到用户张三的授权，微信才会同意"云冲印"读取这些照片。那么"云冲印"怎样获得用户的授权呢？传统方法是，用户将自己的微信用户名和密码，告诉"云冲印"，后者就可以读取用户的照片了。

这样的做法有以下几个严重的缺点：

• "云冲印"为了后续的服务，会保存用户的密码，这样很不安全。
• "云冲印"拥有了获取用户储存在Google所有资料的权力，用户没法限制"云冲印"获得授权的范围和有效期。
• 用户只有修改密码，才能收回赋予"云冲印"的权力。但是这样做，会使得其他所有获得用户授权的第三方应用程序全部失效。
• 只要有一个第三方应用程序被破解，就会导致用户密码泄漏，以及所有被密码保护的数据泄漏。

名称解释：

1. Third-party application：第三方应用程序，本文中又称"客户端"（client），即例子中的"云冲印"。
2. HTTP service：HTTP服务提供商，本文中简称"服务提供商"，即例子中的微信服务器。
3. Resource Owner：资源所有者，本文中又称"用户"（user）。
4. User Agent：用户代理，本文中就是指浏览器。
5. Authorization server：认证服务器，即服务提供商专门用来处理认证的服务器。
6. Resource server：资源服务器，即服务提供商存放用户生成的资源的服务器。它与认证服务器，可以是同一台服务器，也可以是不同的服务器。

2、Oauth2的四种授权模式

1. 密码模式：适用的业务场景，客户端应用(手机app) 是高度受信用的，一般是自己公司开发的app项目。

   

2. 授权码模式：(最安全的模式)，业务场景第三方不授信的，搭建自己的开发能力平台。

   

3. 简化模式：(开发中几乎接触不到，适用于客户端就是一堆js css html 没有前端服务器)

   

4. 客户端模式：(开发中几乎用不到,这种模式用户都没有参与过程)