We saw in previous videos where whenever we want to customize a filter, we need to implement an interface
filter from Java X filter, but that's a pretty basic way of creating your own custom filter because
everything you have to build on your wound.
But for certain scenarios, spring security also provided two important filters called generic filtering.
And once bardic was filtered, the purpose of generic filter being is it also rabu all the properties
and configuration.
So let context details for you.
And whenever you implement this filter, all such properties will also can be leveraged and used by
your own custom filter.
On top of that, it's up to you what you want to write inside your do filter method.
And at the same time, whenever we write a custom filter or any spring security filter present inside
the framework, Spring does not guarantee that that filter will be invoked only once by request.
But if we have a scenario where you want your own custom logic to be executed only once per request,
then you can always extend once per request filter class, which will give you the logic of making sure
that your custom filter will be executable only and once for every request coming from the client.
Let's try to explore them more in the code of the Spring Security Framework.
You can see now how open generic filter bin, which is present inside the spring security framework.
This is an abstract class which already implements filter and at the same time it provides you so many
properties like solid context, environmental details and the configurations that you have done inside
your deployment descriptor file report.
So if you have such scenarios where you want to access the properties and configuration details from
the XML, you can always write your own custom filter by leveraging generic filters.
But at the same time it does not have the implementation of do filter.
Since it's an abstract class.
Whenever you extend it, you have to write your own business logic inside the filter method, which
is specific to your business requirements.
Now let's try to go and see one specific filter and as you can see, once per request for it, that
is a abstract class again, which extends generic filter beyond what this one particular filter will
do is it will make sure that your filter will execute that only once for an entire request.
You can see all the logic of skipping the filter or executing this filter based upon certain conditions
is maintained in this method.
But whatever filter is extending this, once Patrikis filter, it has to implement method to filter
internally because this class already implemented do filter, which handles all the logic of making
sure that your filter will be executed only once by request.
But if we want to write your own logic specific to your custom filter, whenever you extend this class,
you have to make sure that you write your business logic inside, do filter internal and at the same
time you may have certain requirements where your filter should not be executed for certain scenarios.
For all such scenarios, you can leverage should not filter method by overriding it by default, it
always return false.
But if you write your own logic inside it where you don't want your filter to be executed, then this
is the right place.
And at the same time you have to have certain other methods like should not filter asynchronous dispatch,
which is for asynchronous programming and should not filter and dispatch the scenarios where you don't
want the address to be dispatched.
We can check one such implementation of once per request filter, which is our own basic authentication
filter from the spring security.
You can see it extend once per request filter, which means it has to implement all its logic inside
to filter internal but not do filter because the filter is already implemented inside the once per request
filter.
So based upon the scenarios, you can always have three options.
One is directly going and implementing the filter interface, which is plain skeleton from that Java
Excel package.
And either way is by leveraging the generic filter bin where you can get the properties and the configurations
from the XML.
And the last one, which is the most powerful one, if you can implement once per request filter inside
our own custom filter, then you have an advantage of making sure your filter will be executed.
Only once per request and at the same time, you have a control where you can stop executing of your
filter for certain scenarios.
With this, we covered all the concepts in spring security filters in the next video.
Let's try to discuss on the summary what we discussed in this section and close the section.
Thank you.
And by.