Table of contents
1.1. What are authorization rules?
1.2. Configuration of authorization rules
1.2.1. Introduction to configuration information
1.2.2. How to get the request source
a) Add request header information to requests from the gateway
b) Implement the parseOrigin method in the RequestOriginParser interface in the order microservice
c) Add authorization rules in the Sentinel console
2.2.1. Customize abnormal result types
2.2.2. Implement the BlockExceptionHandler interface
1. Authorization rules
1.1. What are authorization rules?
The authorization rule is to judge the identity of the requester and determine whether he has permission to access me.
Everyone will definitely think of the Spring Cloud Gateway here. All requests need to be authenticated through the gateway to see if you have permission to access me. Why do you need an authorization rule here?
You can think of it this way. All requests are routed to microservices through the gateway. At this time, the gateway can authenticate the identity of the requester. However, if there is an insider in your company and the address of the microservice is leaked to people with malicious intentions, those You can bypass the gateway and directly access the microservices, so you need sentinel's permissions to solve this problem.
Sentinel's authorization rules can verify where your request comes from. If it comes from the gateway, it will let you go. If it comes from somewhere else, it will intercept it.
1.2. Configuration of authorization rules
1.2.1. Introduction to configuration information
In Sentinel's console, select Permission Rules to add rules.
- Resource name: It is the "resource" mentioned before, such as /order/{orderId}.
- Flow control application: fill in the name of the caller.
- Authorization type: The white list is the list that is allowed to pass, and the black list is the opposite. For example, if you want the caller to be allowed to come in through the gateway, then fill in "gateway" for the flow control application (configuration is required here, which will be discussed later), and then select Just whitelist.
1.2.2. How to get the request source
There is an interface in Sentinel called RequestOriginParser, and its method called parseOrigin can parse out the source of the requester. Unfortunately, the result returned by this method is always default, so it is impossible to distinguish whether you are coming from the gateway or browsing comes from the interface, so we need to implement this interface ourselves.
Specifically, we only need to make the request header information of the request from the gateway and the request from the browser different, and then make a judgment in the method when implementing the RequestOriginParser interface.
1.2.3. Implementation steps
a) Add request header information to requests from the gateway
Using the gateway filter, add an origin header named gateway.
spring:
cloud:
gateway:
default-filters:
- AddRequestHeader=origin,gateway # 添加名为origin的请求头,值为gateway
b) Implement the parseOrigin method in the RequestOriginParser interface in the order microservice
@Component
public class HeaderOriginParser implements RequestOriginParser {
@Override
public String parseOrigin(HttpServletRequest httpServletRequest) {
String origin = httpServletRequest.getHeader("origin");
if(StringUtils.isEmpty(origin)) {
return "blank";
}
return origin;
}
}
Ps: Add the Component annotation and let the container manage it.
c) Add authorization rules in the Sentinel console
d) Test analysis
Accessing it from a browser will be blocked.
Ps: Here I allow the following resources to pass through the gateway
Therefore access through the gateway will not be blocked
2. Customize abnormal results
2.1. Uses
By default, exceptions will be thrown to the caller when current limiting, downgrading, or authorization interception occurs. As you can see in the case above, the default exception return result is returned directly to the user. Therefore, we can customize the return exception. result.
We only need to implement the BlockExceptionHandler interface. Because this interface is used to handle all the above exceptions.
public interface BlockExceptionHandler {
/**
* 处理请求被限流、降级、授权拦截时抛出的异常:BlockException
*/
void handle(HttpServletRequest request, HttpServletResponse response, BlockException e) throws Exception;
}
2.2. Specific implementation
2.2.1. Customize abnormal result types
BlockException contains many subclasses, corresponding to the following scenarios:
- FlowException: Flow limiting exception.
- ParamFlowException: Exception in hotspot parameter current limiting
- DegradeException: Degrade exception.
- AuthorityException: Authorization rule exception.
- SystemBlockException: System rule exception.
When you implement the BlockExceptionHandler interface to customize the return of exception results, you can return different results corresponding to different types of BlockException.
2.2.2. Implement the BlockExceptionHandler interface
In the order service, implement the BlockExceptionHandler interface.
@Component
public class SentinelBlockHandler implements BlockExceptionHandler {
@Override
public void handle(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse, BlockException e) throws Exception {
String msg = "未知异常";
int status = 429;
if(e instanceof FlowException) {
msg = "请求被限流了!";
} else if(e instanceof DegradeException) {
msg = "请求被降级了!";
} else if(e instanceof ParamFlowException) {
msg = "热点参数限流!";
} else if(e instanceof AuthorityException) {
msg = "请求没有权限!";
status = 401;
}
httpServletResponse.setContentType("application/json;charset=utf-8");
httpServletResponse.setStatus(status);
httpServletResponse.getWriter().println("{message:"+msg+", status:"+status+"}");
}
}
Ps: Don’t forget the Component annotation
2.2.3. Analysis results
This is tested through cases in authorization rules.
It can be seen that direct access through the browser without going through the gateway will trigger a custom result exception.