Like we are discussing in the previous video, spring security framework is built based upon a series
of filters which are maintained in a chain manner, and each filter has its own rules and responsibilities
and wants it done with its execution.
It will handle the logic of execution to the next filter inside the chain.
And based upon the configurations that we do inside our application, these filters will be enabled
or disabled inside spring security flow while starting our application itself.
One such example is if you make calls on CSR of configurations inside your application, then the filters
associated to CSR and courts will be activated and they will be added to the filter chain that maintained
by the spring security.
And at the same time there are mandatory filters also present inside spring security flow, which will
be always executed regardless of what configurations you are making inside your application.
But how can I validate what other filters that has been maintained inside my application?
By the spring security framework, we can really validate what are the registered filters for your application
by making two configurations inside your application?
One is you have to add an annotation on top of your application Springboard saying at the rate enable
web security with the debug is equally true.
So this will start your application in a debug mode.
And at the same time, we should also add one more property, which is logging dot level dot org dot
spring framework, dot security dot dot filter proxy is equal to debug mode.
So this second property indicates framework that I want to log all my Loga statements since I am starting
in the department.
And you can see this is the sample screenshot that will be displayed inside your console based upon
a security filter chain that maintained by your spring security framework.
So in theory, let's try to validate this inside our application for the same.
I will go to my backend application and you can see I have added an annotation on top of my application
with an able Web security and the property debug is equally true.
Similarly, inside your application that properties also you have to add this statement with the property
value is equal to debug.
And this indicates there is a filter chain maintained by spring security and display all the logos associated
with that filter chain since enabling in debug mode.
So let's try to go and see what is there in this filter chain proxy.
As you can see, this is present inside the spring security framework inside that you can go and look
for what you want filtered chain.
And there is a new filter method which has been implemented by spring security team itself, where they
will try to execute the filters present inside a chain one by one based upon their current position.
You can see the current operation will be incremental whenever a filter change is done with its execution
and we will fetch what is the next filter inside the resistor filters and the next filter logic will
be called by invoking do filter method, which is an implementation for that filter.
We can validate this as well by putting a breakpoint here.
So let's try to go and start our application by going to the main class and selecting debug as Java
application and whatever configurations that we discuss should never be enabled or configured inside
a production application.
The reason is this logger's will also print some sensitive information like sectionally tokens and what
are the odds and values?
All such sensitive information will be logged.
Due to that reason.
It is strongly recommended not to make this configuration inside your production applications.
And the same has been printed in the console as well, where Spring security team is saying do not use
in a production system.
So now I clear this Start-Up log, I'll go to my UI, I'll try to perform login operation with the credentials
that I have.
Authentication is successful.
Let's try to go to the back and console and see what information might springboard application printer
and the console.
You can see here there is a lot of.
Security and sensitive information that it has logged along with your authorization, that which includes
your username and password, which is very danger to enable in the protection system, and at the same
time, it also logged what are the current security filter chain that has been configured for our application?
And you can see all these filters will be executed one by one in this order defined here.
That means the very first filter that will execute is this one followed by security context, persistent
filter to the end of the filter chain.
And you can see these two filters got added to the chain because we made configurations related to cards
and Casares inside our application.
And at the same time, basic authentication filter will be added to the filter chain.
Whenever we try to perform authentication and authorization using user name and credentials by making
a configuration of it should be basic.
Our form login inside our projects bring security configuration.
So now we are clear what all the internal filters maintained by spring security based upon the configurations
that we make and how to validate them by making some changes to our logger's inside our application.
Let's try to validate the same one more time by keeping a breakpoint in this matter to filter present
inside the glass virtual filtered chain, which is an inner class inside the chain proxy.
I will try to invoke an operation and you can see here these additional filters will have all the filters
configured by the spring security framework based upon the configurations that we make.
So these are all the filters that has been configured and every filter has its own order, which we
call it as a position as well.
And after invoking of a filter, the current operation will be incremental to call the next to filter
in the chain by fetching it from the additional filters list and invoking that filter method implementation
from that specific filter.
So in this way, spring security will leverage all the filters configured inside our application one
by one in a chain manner.
So now we have a clear understanding on that in the spring security filters.
In the next video, let's try to understand how to write our own custom filter to address our own application
business requirements.
Thank you.
And see you in the next video by.