When I was writing code in ancient times, I wrote a library for permissions. It was basically a generic interface with several methods in it:
For example, when verifying the input principal and credentials, token, authorities and roles are returned. Role is a set of authorities, which means that a stack of authorities is returned. Then each request will use the token to find the authorities, and then determine that the currently requested resource (actually the URL) package is not included in the authorities.
The implementation of this interface is not complicated, and you can also implement it yourself. Because it is an interface, the method parameters in it have a lot of context, so you can basically get all useful information. Back then, there were almost no permission issues that couldn't be solved using this interface.
Later, when I used spring, it was even simpler. I just aopted the controller, and then used a similar interface authentication. If I didn't use aop, I would just use a filter or interceptor.
Later, I found spring security and did a rough study. Okay, AuthenticationManager, AuthenticationProvider, UserDetailsService, SecurityContextHolder, SecurityInterceptor are so dazzling that I don’t know where to start. Moreover, I don’t know if I didn’t pay attention or I was blind, but this thing seems to be strongly coupled to the web or webflux. At that time, there was a requirement that sessions (actually tokens) be placed in redis. A colleague seemed to have to rewrite the entire HttpSession class to implement this simple thing?
Also, because our permission configuration is in another service, do we need to rewrite UserDetailsService when obtaining permissions?
I don’t know if it’s because my colleagues are not good enough or the version is too old, but it made me tremble when I saw it.
Is it necessary to learn this systematically? In fact, after looking at the entire spring security implementation for a long time, it seems that it is no different from my own interface thinking. Now that I have a new project, do I need to learn spring security systematically? Is my understanding too superficial?
Spring Security is a garbage framework
This view is completely correct, because he uses interface concepts to do all extensions, which is only suitable for small and medium-sized projects.
For larger projects, special requirements such as multi-end login and device identification are extremely complex to implement. Once it needs to be changed, the interface it provides simply cannot meet the needs of the enterprise.
shrio is a good framework. Although it is simple, it only takes 2 to 3 days for experienced programmers to implement all spring security functions, and it is more scalable.
It took me a month to learn spring security to master all the knowledge points, but there were too many concepts. After a few months, I was asked to change login, and I was immediately confused. Believe me, when any programmer faces a spring security update, most of them will be confused after a few months or half a year because the original interface cannot be used.
Shrio is different. The interface implementation has almost no changes, but it requires proficiency in jwt and oauth protocols. It takes at most a week to master these two protocols, and even if the login requirements change after a few years, you can still get started quickly.
Those who say that spring security is good, most of them are doing training or pretending to be 13, don't believe it.
Sa-token
I had a rough look at spring security before, but I didn’t understand it very well. I added sa-token to the project according to the official documentation. It feels really simple, and it can also realize the automatic renewal of the token. It’s so cool!
This article is published by OpenWrite, a blog that publishes multiple articles !