Yesterday, due to the integration of spring security oauth2, some changes were made to the previous spring security configuration, and then it was not possible to jump back to the blocked page correctly after login, but instead returned to the localhost root directory.
Started thinking it was intercepted by oauth2, causing a problem, but the security interceptor is a priority, so it's not possible.
Finally, there's no point in interrupting. Debugging (redirect to spring security login to the URL that was accessed before the interception process)
The picture is seen here in 49535413
As you can see from the diagram, the request to save the interception is in this class.
Httpsessionrequestcache
Search for this class in idea, set a breakpoint in the Saverequest method, and then debug
Debug discovery when the browser enters a URL with permission restrictions (such as/admin/console), the system calls the Saverequest method to cache the current request object (as shown)
Since the save is/admin/console, but why take out is/, continue to find the problem, the system calls a Saverequest method, and this time save the request object is "/" path
That is, the previous preservation is to be covered by this, through the source can be found, the Saverequest method is to cache the request object to the session, And the key value is a static value (this shows that if we want to customize some methods, we can remove the saved request object from this key value, but the system also provides the Getrequst method)
According to the flowchart, only intercepted requests will be captured and saved, so I went to check my websercurityconfig, found that in addition to static resources all other resources need to verify, and therefore "/" root directory is blocked, "/" added to the exclusion list problem resolution
The "/" was discovered through subsequent debugs because the request was made by my custom login page
It is important to note that spring security completed user login after the transfer of the original page processing is in
Savedrequestawareauthenticationsuccesshandler class, override this method if you want to customize the operation after a successful login to inherit the class
But I was writing it. This method of calling the parent class automatically generated in the generated code causes the saverequest to be obtained (that is, the following line)
The reason is that in
When the Savedrequestawareauthenticationsuccesshandler class is processed, the cache in session is deleted after getting to Saverequst
Spring security does not return to the previous request interface after using the custom login interface