Last post was a simple introduction to the use of Loki logging platform, and today a simple study of how to use Loki in practice to monitor Spring Boot applications, specially shared to give you a deeper understanding of this new technology. Loki’s log collection practice In previous article we used Docker Compose to start Grafana, Loki, and Protail at the same time to monitor an application. And the architecture of the whole logging system.

The project is formalized, the logging system is indispensable. The majority of logging platforms recommended to build based on ELK, but ELK is relatively heavy, the architecture is too large, small and medium-sized projects are not very good to hold, I hope to find a simple, if you really can not find then use ELK. before the reserve some technical candidates library, looked through the fruit of a logging system

The ResponseEntity object is Spring’s wrapper around the request response. It inherits from the HttpEntity object and contains the Http response code (httpstatus), the response header (header), and the response body (body). A Spring MVC interface to get user information usually we return the entity directly (with @RestController). 1 2 3 4 5 6 @GetMapping("/user") public User userinfo() { User user = new User(); user.setUsername("felord.cn"); return user; } is equivalent

In some scenarios we need to get who the current user is? If you are using Spring Secrity as a security framework you can get the current user by using the following means. SecurityContext Either in stateful Session mode or in the popular JWT mode you can use SecurityContext to get the current user. 1 2 Authentication authentication = SecurityContextHolder.getContext().getAuthentication(); String currentPrincipalName = authentication.getName(); Of course, this approach is not rigorous enough, if the interface allows anonymous access is likely to return an anonymous user, and anonymous users can not be obtained directly through getName, so we need to optimize the above logic.

In the previous posts, I joined you for a cursory look at Keycloak. As I gradually learned more, I found that I entered a misunderstanding, originally I thought that the focus of Spring Security integration with Keycloak was on this aspect of Spring Security, in fact, I found that Keycloak has no room to work with several filters on Spring Security’s Adapter, perhaps it needs I think we need to understand Keycloak itself before we can have a breakthrough.

When using Keycloak, you may have noticed that user management is done through the UI provided by Keycloak, which is convenient but often not suitable for use in development. For example, you can’t let end-users go directly to Keycloak’s Admin Console to register. Therefore, it is necessary to APIize these functions, and today we are going to share a method to operate Keycloak through programming. Introduction to Keycloak Admin Client

In the previous article we got familiar with the common configuration of Keycloak, today we will do an analysis of the execution flow of Keycloak adapted to Spring Security and briefly understand some of its customized Spring Security filters. Execution flow of /admin/foo In the Spring Boot application adapted with Keycloak and Spring Security, I wrote a /admin/foo interface and configured the permissions for this interface as follows. 1 2

In the last Keycloak article, we successfully adapted Keycloak to Spring Security with a keycloak.json configuration. It contains quite a few properties that I feel we need to learn together as we go deeper into the process. Common properties of Keycloak adapters realm Domain name, this is a mandatory item. resource The application’s client_id, a unique identifier for each client registered on the Keycloak server. This is a mandatory item.

Keycloak provides adapters for popular Java applications. In previous articles, we demonstrated security protection for Spring Boot using one of the adapters. Keycloak also provides adapters for Spring Security, and in the following articles we will learn together about the use of Spring Security adapters. The installation of Keycloak can be found in the previous tutorials in the series. Adapter integration In our Spring application we integrate keycloak-spring-security-adapter. 1 2

In the previous article we reviewed the OAuth 2.0 process with an example, and pointed out the limitations of OAuth 2.0: The client cannot identify the resource owner as the correct advocate, and while commercially available OAuth 2.0 can guarantee authorization security, OAuth 2.0 itself does not provide clear specifications for user authentication. This is where OIDC comes into play. OIDC OIDC is a variant of OAuth 2.0. OIDC (OpenID Connect) builds on the Auth 2.

In the previous article we did a hands-on exercise on Keycloak protecting Spring Boot applications. We showed you how powerful Keycloak is. But in order to master Keycloak you need to understand the OpenID Connect (OIDC) protocol. OIDC is an extension of OAuth 2.0. Why does it extend OAuth 2.0? Before we can figure this out we need to review the OAuth 2.0 protocol again. OAuth 2.0 We’ve talked a lot about the OAuth 2.

This article tries out the keycloak counterpart of the Spring Boot Adapter to see how keycloak protects Spring Boot applications. Client I believe many of you have used WeChat Open Platform and Ant Open Platform. First we need to register a client on these open platforms to get a set of credentials like username and password. Some of them are called appid and secret; some are called clientid and secret,

This article will further experience Keycloak, give us an intuitive understanding of it, and then go deeper and deeper to break down its design concepts and ideas. General idea Since we already know beforehand that Keycloak provides an adapter for Spring Security. Let’s first get the core concepts of Keycloak clear independently and then work on how it incorporates Spring Security. Installing Keycloak The Keycloak version for this article is 14.

Recently, I want to open up the user relationship of several applications and get a centralized user management system to unify the user system of the application. After some research, I selected Red Hat’s open source Keycloak, which is a very powerful unified authentication authorization management platform. The reason why Keycloak was selected is based on the following reasons. Ease of Use Keycloak provides a one-stop single sign-on solution for web applications and Restful services.

The annual SpringOne conference was held online last September 1-2 due to an epidemic, and Pivotal (the owner of the Spring Project) hosts this conference once a year to meet with thousands of developers, customers and partners from around the world to share technical practices and discuss technology trends. Each conference also reveals the next big step in the Spring Project’s evolution. The highlight of this year’s conference is definitely Spring Framework 6.

SpringMVC has a complete system for handling exceptions, and it works very well. This article talks about the exception handling system in SpringMVC. We will sort out the exception system in SpringMVC from beginning to end. 1. Exception Resolver Overview In SpringMVC’s exception system, the big boss at the top is the HandlerExceptionResolver, an interface with a single method. 1 2 3 4 5 public interface HandlerExceptionResolver { @Nullable ModelAndView resolveException( HttpServletRequest request, HttpServletResponse response, @Nullable Object handler, Exception ex); } The resolveException method is used to resolve the exceptions generated during the request processing and eventually return a ModelAndView.

I have been using JWT as authentication token for my projects in the last few years. I’ve always had a question: where exactly should the server-side issued JWT be stored? Only the browser scenario is discussed here, in which there are three options. Cookies The server side can send the JWT token to the browser through a cookie, and the browser will automatically bring the JWT token in the cookie header when requesting the server-side interface, and the server side can verify the JWT token in the cookie header to achieve authentication.

Certain business requirements require tracking our interface access, i.e. logging the requests and responses. The basic logging dimension contains request parameters (path query parameters, request body), request path (uri), request method (method), request headers (headers), and response status, response headers, and even contains sensitive response bodies, etc. Today summarizes several methods, you can choose as needed. How request tracking is implemented Gateways Many gateway facilities have httptrace capabilities that help

Spring Authorization Server 0.2.2 is released, this version is mainly about optimizations and bug fixes, the more important new feature is Client authentication support for JWT assertions. Release Notes New features JdbcOAuth2AuthorizationService now supports large database fields. Deprecated OAuth2TokenIntrospectionClaimAccessor, will use Spring Security 5.6 implementation. Deprecate JwtEncoder related classes and use Spring Security jose library implementation. The token field in the JdbcOAuth2AuthorizationService now supports clob and text data types. Token revocation logic is now customizable.

Maven 1 2 3 4 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-mongodb</artifactId> </dependency> Multiple Data Source Configuration Configuration file. 1 2 3 4 5 6 7 8 spring: data: mongodb: uri: mongodb://192.168.150.154:17017 database: ewell-label mongodb-target: uri: mongodb://192.168.150.154:17017 database: ewell-label-target java configuration Master data source 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30