育儿语录：男孩子生性自由，不善服从；对待他们，当以诚恳和率直的态度，帮助他们建立起勇气。

“外卖员人命不值钱。”

前几天，奔驰男出言不逊 ，被美团外卖员一顿殴打。

神奇的是，美团方竟然没怎么回应，不像之前顺丰快递小哥被打了之后，王卫直接霸气回应：“如果我这事不追究到底！我不再配做顺丰总裁！”

不回应归不回应，毕竟这是一桩社会事件，颇有点复杂。一旦回应不好，容易引来争议。

不过，最近美团倒是真正从外卖员利益出发，做了一件值得点赞、没什么争议的大事。

11月26日，美团外卖举办“骑手体验与生态建设”沟通会。会上，美团配送总经理魏巍表示,通过53场恳谈会，美团方充分了解到骑手的工作痛点，其中有代表性的就是，商家出餐慢以及联系不上顾客等问题。

美团明确表示，下阶段将重点解决这些问题，其中，非常引人关注的便是在骑手体验层面，增加骑手评价商户的功能。

万万没想到，外卖员也可以点评商家了！

该消息一出，立马受到诸多好评。

普通消费者表示，外卖小哥挺不容易的，很多时候明明就是商家出餐慢，导致外卖员超时。有了这个功能，商家也会更注意出餐时间了。

外卖员则表示，这个操作，真是太为骑手考虑了，一直以来都是因为超时被点差评，现在终于也能点评商家了。

不过，也有商家表示担心，如此一来，生意越来越难做了，不仅要讨好消费者、还要讨好骑手，平台方更是要讨好。

当然，也有网友指出，美团的做法有转移矛盾的嫌疑，商家的出餐时间可以通过平台算法设置，进行规范。外卖小哥超时的本质原因，在于平台算法没考虑出餐时间。

任何一个新制度的诞生，初期难免会受到质疑。很多根本性问题，或许不能一步到位、彻底解决。但美团此次改革，至少是一个好的开始！

没有无缘无故的改革，美团心里门儿清！

外卖员和商家之间的矛盾，由来已久！

今年10月底，一段外卖小哥和店家互殴的视频在网上流传。

视频中，外卖小哥先是同店家争执，而后情绪失控砸了店家的东西。随后，店家拿起勺子砸向外卖小哥，并用脚狠踹外卖小哥。一开始怒砸东西的外卖小哥，最后只是缩成一团，蹲在地上崩溃大哭。

在接受媒体采访时，外卖小哥回应，当时自己因为等了20分钟，手中还有5单，因为担心耽搁被罚钱，情急之下催了店家。店家却没好气地答道：“爱送不送，不送拉到。”一时间，外卖小哥被激怒了，才没忍住动了手。

外卖小哥动手在先，并不占理。但店家出餐慢，影响外卖员收入，也是事实。他们之间的核心矛盾，就在于出餐时间。

此类恶性事件还有很多，有的甚至演变到违法犯罪。2017年11月，山东发生一起外卖小哥持刀砍人事件，原因也在于外卖小哥嫌商家出餐慢，一怒之下砍伤了米线店老板和员工。2019年12月，武汉一外卖小哥因与商户店员发生口角，事态失控，外卖员用刀刺死了店员。

外卖员和商家之间，没有无缘无故的矛盾。

美团作为平台方，自然也看在眼里。毕竟每次一出事，大家在指责外卖员和商家素质堪忧的同时，更多的是指出美团配送机制的不合理。而评价机制的上线，能更好协调外卖小哥和商家之间的矛盾，约束店家的出餐时间，减少恶性事件的发生。

从看到问题到解决问题，美团终于迈出了一大步。

首先，对外卖员来说，在催促之外，多了一种更温和、和谐的选择。以前，商家出餐慢了，外卖员只能急得干跺脚，催的语气重了点，还可能大打出手，落得个送餐迟到、差评、罚款的下场。如今，能够掌握一定的主动权，约束商家。

再者，对消费者来说，体验也会更好。评价机制下，外卖员感受到了平等，工作热情和积极性都会提高，服务自然也会变好。而且增加了这个功能，外卖员也会成为倒逼商家提高服务质量的一环。

总之，在美团的业务中，外卖员作为服务基石，早就应该得到平台方的体谅和保护。不得不说，美团的这53场骑手恳谈会不是白开的。至少，在公众舆论之外，美团也开始倾听骑手的声音，并切实作出改变了！

犹记得几个月前，《外卖骑手，困在系统里》传遍网络，两大外卖巨头被推上风口浪尖。

饿了么率先回应，把主动权交给用户，“多等5分钟，缓解外卖小哥压力。”美团姗姗来迟，坦诚没做好就是没做好，并为外卖员留出8分钟的弹性时间。

这一回合，美团略胜一筹。而如今，美团再次走在了饿了么的前面。

值得注意的是，外卖员评价商户功能背后，美团还有更大的改革决心。

11月26日的 “骑手体验与生态建设”沟通会中，美团高级副总裁、到家事业群总裁王莆中表示，美团将推出“同舟计划”，从工作保障、体验提升、职业发展、生活关怀四个层面提升骑手体验与生态建设。与此同时，将继续倾听骑手的声音，到2021年，骑手恳谈会将增至196场。

骑手评价商户之外，美团也将升级骑手申诉流程，加速铺设智能取餐柜，配备智能头盔，提供更多职业培训和骑手关怀活动。

这种种，都是美团未来改革的方向。“同舟”二字，取同舟共济、风雨同舟等意，这也凸显出了美团对外卖骑手的关注。

作为近些年新崛起的外卖巨头，美团有社会责任和义务去改善外卖小哥的工作处境。

总之，做，总比不做好；迟到，总比缺席好。

同属于劳动密集型产业老大的王卫曾说过：“员工的幸福才是我王卫长期努力的方向”，“一线小哥都是顺丰一哥”。希望有一天，外卖小哥也能收获更多幸福，得到更多官方认可和关怀！

人生如同一杯茶，只有漫漫地品味才能品出它的味道来；

人生如同一首诗，只有反复地咀嚼才能读出它的意韵来；

人生如同一首歌，只有静下心来才能听出它的律动来。

各位下载的时候顺手给个小星星好不。。

各个知识点 起到的作用：

oauth2：  授权的，这个“2”  的意思是，授权的是第二方，如，我们可以用qq账号登录很多网站，这个qq的授权服务相对于你要登录的网站就是第二方。

 直白的说： oauth2 给用户授权，spring security 根据你的权，开放给你页面访问，这个就是单点登录的核心所在了

既然有第二方授权，那么后台的服务肯定不止一个，正如我上面提供的两个git 项目地址一样，我把整套机制汇总到了两个服务里面——1、客户端 2、认证服务器（包括资源服务器）

上面地址 是 来讲述 oauth2 框架原理的，我没仔细看（那也得有时间去看。。），我之前大把精力用来实现功能上了，而且这种封装好的，除非你想改源代码，知道不知道原理，实现起来 一样的，但是大致过程肯定是要清楚地。

和shiro 框架采用token 认证不一样， oauth 采用了从cookie 里面获取token的方法，只需要使用一次，并且一旦确定你的登录合法，之后开放给你的网址权限就全部开放了，不会像shiro 一样每次访问一个接口都要带上token。（我有什么讲错的可以评论里跟我讲） 我把  resource server 和 authorization server 合为一个服务，这是通用的做法。

突然发现要讲的东西好多，我还是从功能点来一个个讲吧。

 1、用户访问客户端网址 --》2、用户没有登录（ 即网址没有被授权） --》3、跳转到auth-server （认证服务器,下面只写英文）--》4、用户注册并登录账号密码（并成功后）--》5、跳转到原本想访问的那个网站（此时有了访问该网站的权限）

如果用户关闭了浏览器，（并没有清理cookie）则当用户第二次访问想要访问的网站时，可以直接进入（cookie 里保存的token未过期的情况）

如果用户手动退出，则需要再次在auth-server 登录账号密码访问 网站。（其实就是主动让cookie里的token过期，并跳转到登录界面而已）

authorizeReuqests()   干啥呢，看名字—— 需要权限，结合上面 那就是 所有 ‘/’ 开头的都要要权限，所以基本都要权限了

正如上面所说，访问不了 secure.html  ,你需权限，你还没登录，这怎么办呢，没事，这个跳转你只需要配置，我们加的Oauth2依赖就给你设计好了怎么跳转等细节问题.， 其实仔细看代码的话，可以看到 client 的 OauthConfig 类 有一个 注解

表明这个是 Oauth2 的客户端

yml 文件配置如下：

这个是固定的，除非你自定义接口地址，作用就是 上面图中的 token  cookie  拿来拿去的地址，很复杂的，详细请看上面链接。

虽然到时候auth-server 里写的接口很简单，但那是框架设计的好。

在访问client web网页的时候，如果是需要授权，则在“检查”里的状态值为“302”  如我要点击client 页面的a标签后，本应跳转到相应的7778 端口的secure.html 页面，可以发现去了auth-server （7777端口）的登录界面，检查（F12）看一下发生了什么

 三个302 的状态之后，到了一个200 状态的login 页面，，简单的概括这个过程，就是服务器端发现你没有认证，那么就会给你经过一系列重定向网址到登录界面，如果说你已经登录过了，我们可以看看差别（还是那个链接点击）

可以看到直接就进入了，其实因为在客户顿和服务器都保存了必要的cookie 和 session 数据的缘故，我们在推出，然后重新登录，可以看到下面network 里面 经历了  一个authorize?xxx (红框） 和 login?xxx(蓝框） 这两个重定向网址的过程，我们可以猜测就是这两个过程，分别在服务端和客户端记录了必要的信息，这是下次登录直接可以进入的前提，除非这些信息过时了。

这个乏善可陈吧，其实定义好Entity类，一些注解我就不讲了，主要是User类中  @ManyToMany（多对多关系）的注解需要一定得数据库知识和对jpa 的理解。以为实体只有两个 —— user、role  其实还需要将这两张表关联起来，就用到了第三张表，其实就是我们学习数据库课上ER图里面的 “关系”，ER图里面不仅实体可以生成一张表，关系也会成为一张表（我数据库的老师看到会感动的要死，我真的还记得~）

 所以这个注解、属性的意思呢，就是我需要有这个 “user_role” 的关系（表），知识点来了，jpa根据 这个 名称就知道，这是那两张表的关系了！！！，你如果不信，可以试试，我没试过，我在看一篇外国文章的时候偶然发现的，一下子让我懂了这个注解的工作原理。 知道是那两张表的关系，我们就需要设定 这个 关系（表） 里的字段名称为什么，如上，是user_id,  role_id 可是这两个字段的类型分别是什么呢，没错，就是 user 、role 表的主键啊，进而联想到外键的定义，user_id,role_id 不就是两个外键吗，而且，其实这两个字段还是user_role 表的两个主键（主键可以是一组o）

为了不下载代码的小伙伴也能看的更清楚，我还是放一下这两个Entity 的代码吧：

然后 分别创建两个repository 接口就可以使用jpa 提供的数据库crud方法了

就可以在spring boot 运行的时候自动生成所需的mysql 的表了，没错，按照Entity自动生成对应table。理论上连数据库的名字也是可以自动生成的，不过我没找到响应的方法，所以还是需要手动先创建一个数据库，如我一开始所说的。

可能有冗余，因为我参考了好多项目，所以先都拿过来用了，也可以看出我这之间尝试的次数之多，真的是这里的配置如果没有人来指点，要话费整个项目编写的整整一半时间！这个绝非危言耸听。一行行来讲，和client 一样的就不讲了 其实好多网上教程都是让你进的默认login界面，这样学的人就不能进行一些功能上的扩展了。 进而我们设置 失败界面failureUrl、成功路径defaultSuccessUrl 注意：这个成功路径必须是我们client 端的响应路径 即应该跳转到的 localhost：7778/ui/secure 这样才能回去，有的项目不用设置也可以回去，这个我没有试过，但就是回不去。。 .passwordParameter("password") 这两行制定了我们验证用户的方式，表明需要 用 email 和 password 来验证，在哪里验证? 其实，你一开始是否有疑问，为什么我们可以自定义login登录页面，也可以使用默认的login页面，这是因为，无论选择何种，最后都需要发送两条信息 post 到 auth-server的 /login 地址，注意，是post 不是get get /login 返回的是login 页面， post /login 是将输入的数据发送到 /login 接口 至于这两条数据的id （待会儿 thymeleaf 里面需要设置）即分别是 “email”，和 “password” ,默认情况下你也可以进入默认登录页面查看两者id，以上，我觉得应该描述清楚这两行的作用了。 .accessDeniedPage("/access-denied") 这里呢，又是 一串重定向。。不过这里是以后单点管理端可以使用的退出设置（和客户端退出不一样！！！ ，听到这里你是不是也晕了，上面这个没用到就不讲了，客户端退出过程先讲） // 从哪来回哪去，经过上一步肯定还要验证的

这个referer 是什么呢，来一张截图： （我按了上面的退出 按钮）

为什么会从secure 重定向到 login呢 ，你是不是懵逼了？

“/”  “/login**” 这两个地址 设置了不需要权限的访问，其他网址访问需要授权，未授权则到auth-server 统一授权了才能再进去，可能会有人问，如果client 客户端有多个了怎么办？  

事实上，我们可以定义多个返回值，根据不同的客户端，   里面截取一段

我们就是回到了这个  中间过程，然后再进入secure页面。

 这里用了  jdbcAuthentication() 方法，然后两条语句也是自己写的，说起来其实就是查找用户姓名和角色，具体再配置文件里

 其实这里有很多认证方法，包括UserDetailService 等等，我之前看到简书里面有个人写的不错，到时候把他的文章链接也放到这里来好了，我就不再赘述。

记住，这个部分，我在国内还没看到有人提过具体事项

因为我在做单点登录的过程中，遇到了登录之后，跳转不回之前页面的问题，我在国内查找资料毫无进展，还在stackoverflow 上面提问了， ，结果在之后一次查阅资料的时候，也是在stackoverflow上找到了解决方法

这个因为Oauth2 版本问题？ 我之前在国外网站学习的时候，是没有这个注解的，比如  

虽然配置所需代码就那么几行。。。

我感觉讲了好多，这个部分我就很简单的讲讲。

对应的viewname  = registration， 那么这个就是 registration.html 文件了，可以看到加了一个“user” 的信息进去，那么我们就可以再相应的html文件里获取到这个信息，这里其实使用了一个表单

到时候表单发送，就把整个user 对象发送到对应接口

视图层面和 controller 层的交互就都是类似的实现，上面的例子还是比较复杂的一种，简单的单独加个内容什么的，项目里面也是很好找的。

我感觉还有好多知识点没有讲，实在是东西有点复杂，我本人也是还在研究阶段。

日后再有改进，或有其它任何问题，继续再更