服务程序集成了OAuth2-Client，以便于用户能够方便集成到支持OAuth2第三方登录的自有业务系统中。开发完成后，本地测试、或者直连服务程序，都没有问题。但凡放到线上环境，经过了nginx 转发后，我们的服务程序OAuth登录永远是以失败告终。
现象如下：
访问需要授权的接口时 https://blog.95id.com:4005/user_attr，期望是跳转到授权服务器 github.com进行登录授权，但实际都是跳转到``http://blog.95id.com/login`
因为当时直接用服务程序的端口没问题，就将解决思路放在了nginx 转发过程上。
当时线上环境路由规则类似于：
第一层：nginx1 4005 （ssl、负载均配置在这）
第二层：nginx2 4005
第三层：oauth2-client 8082
再看nginx 的配置，第一层nginx 配置：
pom.xml
1 | <dependency> |
application.properties
1 | =mongodb://user:pwd@ip:27017/database |
集群版mongodb
1 | =mongodb://user:pwd@ip1:port1,ip2:port2/database |
基于spring boot的一个小项目，前后端分离，采用REST风格的接口设计，在做权限设计时觉得以前的权限控制实现比较繁琐，一个Action就对应一条Permission。所以想着接口可以走REST风格，权限为什么不可以呢？比如称作READ风格的权限控制(Representational Authorization Design)……
REST早已不是新鲜事物，基于REST的权限控制网上也是有现成的，基于RESTful API 怎么设计用户权限控制？写得很棒，所以基于这篇文章的设计思路做了个实现(java)。本文的前半段，主要是引用文章阐述设计思路，后半部分主要为程序code实现。
其中后端自定义一个过滤器做权限过滤，用到了spring util包下的AntPathMatcher做权限规则匹配；前端也就一个directive就搞定了。技术上并没有引用什么技术框架，关键还是抽象思维且将设计思路转化为程序上code。
传统的权限配置 vs 权限被抽象成资源和状态
1 | /getUsersGroups?id=1 |
vs
1 | GET /users/** 表示 对 users 资源 及events 附属的资源 有获取/浏览的权限 |
场景：
方案：在一个确切的地方存储 数据源的配置信息（我是将这些信息存储在一个 配置数据库表中，而这个配置数据库是确切的，作为主数据源配置）。启动spring时，会初始化这个配置数据源，然后将其他动态数据源信息取出来初始化好datasource 注册到spring 容器。
原理：主要是实现AbstractRoutingDataSource的抽象类，然后将该类注册到spring容器，其中关键点是：
Object defaultTargetDataSource 和其他数据源Map<Object, Object> targetDataSources。targetDataSources就是我们动态配置的数据源，key-value 接口，后面根据key 查找 datasource Update your browser to view this website correctly. Update my browser now
