1
00:00:00,180 --> 00:00:07,890
We saw in previous videos where whenever we want to customize a filter, we need to implement an interface

2
00:00:07,890 --> 00:00:14,700
filter from Java X filter, but that's a pretty basic way of creating your own custom filter because

3
00:00:14,700 --> 00:00:17,670
everything you have to build on your wound.

4
00:00:17,730 --> 00:00:26,100
But for certain scenarios, spring security also provided two important filters called generic filtering.

5
00:00:26,220 --> 00:00:34,650
And once bardic was filtered, the purpose of generic filter being is it also rabu all the properties

6
00:00:34,650 --> 00:00:35,990
and configuration.

7
00:00:36,000 --> 00:00:38,400
So let context details for you.

8
00:00:38,670 --> 00:00:45,840
And whenever you implement this filter, all such properties will also can be leveraged and used by

9
00:00:45,840 --> 00:00:47,240
your own custom filter.

10
00:00:47,370 --> 00:00:52,890
On top of that, it's up to you what you want to write inside your do filter method.

11
00:00:52,980 --> 00:00:59,310
And at the same time, whenever we write a custom filter or any spring security filter present inside

12
00:00:59,310 --> 00:01:05,570
the framework, Spring does not guarantee that that filter will be invoked only once by request.

13
00:01:05,760 --> 00:01:13,140
But if we have a scenario where you want your own custom logic to be executed only once per request,

14
00:01:13,350 --> 00:01:21,390
then you can always extend once per request filter class, which will give you the logic of making sure

15
00:01:21,390 --> 00:01:27,340
that your custom filter will be executable only and once for every request coming from the client.

16
00:01:27,450 --> 00:01:31,420
Let's try to explore them more in the code of the Spring Security Framework.

17
00:01:31,560 --> 00:01:38,100
You can see now how open generic filter bin, which is present inside the spring security framework.

18
00:01:38,430 --> 00:01:46,320
This is an abstract class which already implements filter and at the same time it provides you so many

19
00:01:46,320 --> 00:01:53,780
properties like solid context, environmental details and the configurations that you have done inside

20
00:01:53,820 --> 00:01:56,430
your deployment descriptor file report.

21
00:01:57,000 --> 00:02:03,300
So if you have such scenarios where you want to access the properties and configuration details from

22
00:02:03,340 --> 00:02:10,080
the XML, you can always write your own custom filter by leveraging generic filters.

23
00:02:10,560 --> 00:02:14,640
But at the same time it does not have the implementation of do filter.

24
00:02:14,970 --> 00:02:16,350
Since it's an abstract class.

25
00:02:16,510 --> 00:02:22,410
Whenever you extend it, you have to write your own business logic inside the filter method, which

26
00:02:22,410 --> 00:02:24,780
is specific to your business requirements.

27
00:02:25,000 --> 00:02:31,560
Now let's try to go and see one specific filter and as you can see, once per request for it, that

28
00:02:31,770 --> 00:02:38,880
is a abstract class again, which extends generic filter beyond what this one particular filter will

29
00:02:39,180 --> 00:02:45,310
do is it will make sure that your filter will execute that only once for an entire request.

30
00:02:45,480 --> 00:02:53,010
You can see all the logic of skipping the filter or executing this filter based upon certain conditions

31
00:02:53,220 --> 00:02:54,870
is maintained in this method.

32
00:02:55,020 --> 00:03:04,530
But whatever filter is extending this, once Patrikis filter, it has to implement method to filter

33
00:03:04,680 --> 00:03:10,950
internally because this class already implemented do filter, which handles all the logic of making

34
00:03:10,950 --> 00:03:14,180
sure that your filter will be executed only once by request.

35
00:03:14,460 --> 00:03:20,340
But if we want to write your own logic specific to your custom filter, whenever you extend this class,

36
00:03:20,670 --> 00:03:25,500
you have to make sure that you write your business logic inside, do filter internal and at the same

37
00:03:25,500 --> 00:03:31,890
time you may have certain requirements where your filter should not be executed for certain scenarios.

38
00:03:32,160 --> 00:03:38,880
For all such scenarios, you can leverage should not filter method by overriding it by default, it

39
00:03:38,880 --> 00:03:40,830
always return false.

40
00:03:40,950 --> 00:03:48,000
But if you write your own logic inside it where you don't want your filter to be executed, then this

41
00:03:48,000 --> 00:03:48,840
is the right place.

42
00:03:48,840 --> 00:03:54,600
And at the same time you have to have certain other methods like should not filter asynchronous dispatch,

43
00:03:54,600 --> 00:04:00,480
which is for asynchronous programming and should not filter and dispatch the scenarios where you don't

44
00:04:00,480 --> 00:04:02,160
want the address to be dispatched.

45
00:04:02,340 --> 00:04:09,240
We can check one such implementation of once per request filter, which is our own basic authentication

46
00:04:09,240 --> 00:04:10,830
filter from the spring security.

47
00:04:11,010 --> 00:04:18,730
You can see it extend once per request filter, which means it has to implement all its logic inside

48
00:04:19,140 --> 00:04:26,130
to filter internal but not do filter because the filter is already implemented inside the once per request

49
00:04:26,130 --> 00:04:26,580
filter.

50
00:04:26,730 --> 00:04:30,870
So based upon the scenarios, you can always have three options.

51
00:04:30,870 --> 00:04:37,880
One is directly going and implementing the filter interface, which is plain skeleton from that Java

52
00:04:37,890 --> 00:04:39,030
Excel package.

53
00:04:39,240 --> 00:04:46,530
And either way is by leveraging the generic filter bin where you can get the properties and the configurations

54
00:04:46,530 --> 00:04:47,840
from the XML.

55
00:04:47,970 --> 00:04:53,880
And the last one, which is the most powerful one, if you can implement once per request filter inside

56
00:04:53,890 --> 00:04:59,430
our own custom filter, then you have an advantage of making sure your filter will be executed.

57
00:04:59,730 --> 00:05:07,100
Only once per request and at the same time, you have a control where you can stop executing of your

58
00:05:07,110 --> 00:05:09,150
filter for certain scenarios.

59
00:05:09,290 --> 00:05:15,290
With this, we covered all the concepts in spring security filters in the next video.

60
00:05:15,420 --> 00:05:20,200
Let's try to discuss on the summary what we discussed in this section and close the section.

61
00:05:20,400 --> 00:05:20,900
Thank you.

62
00:05:20,910 --> 00:05:21,360
And by.