1
00:00:00,240 --> 00:00:06,990
Like we are discussing in the previous video, spring security framework is built based upon a series

2
00:00:06,990 --> 00:00:14,910
of filters which are maintained in a chain manner, and each filter has its own rules and responsibilities

3
00:00:15,150 --> 00:00:17,880
and wants it done with its execution.

4
00:00:18,010 --> 00:00:23,190
It will handle the logic of execution to the next filter inside the chain.

5
00:00:23,400 --> 00:00:30,600
And based upon the configurations that we do inside our application, these filters will be enabled

6
00:00:30,600 --> 00:00:36,340
or disabled inside spring security flow while starting our application itself.

7
00:00:36,540 --> 00:00:45,630
One such example is if you make calls on CSR of configurations inside your application, then the filters

8
00:00:45,630 --> 00:00:54,210
associated to CSR and courts will be activated and they will be added to the filter chain that maintained

9
00:00:54,210 --> 00:00:55,470
by the spring security.

10
00:00:55,620 --> 00:01:02,610
And at the same time there are mandatory filters also present inside spring security flow, which will

11
00:01:02,610 --> 00:01:08,460
be always executed regardless of what configurations you are making inside your application.

12
00:01:08,610 --> 00:01:15,030
But how can I validate what other filters that has been maintained inside my application?

13
00:01:15,030 --> 00:01:21,330
By the spring security framework, we can really validate what are the registered filters for your application

14
00:01:21,480 --> 00:01:25,030
by making two configurations inside your application?

15
00:01:25,200 --> 00:01:33,000
One is you have to add an annotation on top of your application Springboard saying at the rate enable

16
00:01:33,000 --> 00:01:36,030
web security with the debug is equally true.

17
00:01:36,150 --> 00:01:40,140
So this will start your application in a debug mode.

18
00:01:40,140 --> 00:01:47,250
And at the same time, we should also add one more property, which is logging dot level dot org dot

19
00:01:47,250 --> 00:01:54,370
spring framework, dot security dot dot filter proxy is equal to debug mode.

20
00:01:54,540 --> 00:02:02,670
So this second property indicates framework that I want to log all my Loga statements since I am starting

21
00:02:02,670 --> 00:02:04,070
in the department.

22
00:02:04,200 --> 00:02:11,350
And you can see this is the sample screenshot that will be displayed inside your console based upon

23
00:02:11,370 --> 00:02:16,430
a security filter chain that maintained by your spring security framework.

24
00:02:16,560 --> 00:02:22,940
So in theory, let's try to validate this inside our application for the same.

25
00:02:23,310 --> 00:02:30,270
I will go to my backend application and you can see I have added an annotation on top of my application

26
00:02:30,450 --> 00:02:35,270
with an able Web security and the property debug is equally true.

27
00:02:35,580 --> 00:02:42,900
Similarly, inside your application that properties also you have to add this statement with the property

28
00:02:42,900 --> 00:02:44,790
value is equal to debug.

29
00:02:44,910 --> 00:02:54,210
And this indicates there is a filter chain maintained by spring security and display all the logos associated

30
00:02:54,330 --> 00:02:58,110
with that filter chain since enabling in debug mode.

31
00:02:58,350 --> 00:03:01,770
So let's try to go and see what is there in this filter chain proxy.

32
00:03:01,950 --> 00:03:08,460
As you can see, this is present inside the spring security framework inside that you can go and look

33
00:03:08,460 --> 00:03:10,230
for what you want filtered chain.

34
00:03:10,440 --> 00:03:18,630
And there is a new filter method which has been implemented by spring security team itself, where they

35
00:03:18,630 --> 00:03:26,540
will try to execute the filters present inside a chain one by one based upon their current position.

36
00:03:26,670 --> 00:03:34,800
You can see the current operation will be incremental whenever a filter change is done with its execution

37
00:03:35,010 --> 00:03:43,050
and we will fetch what is the next filter inside the resistor filters and the next filter logic will

38
00:03:43,050 --> 00:03:49,380
be called by invoking do filter method, which is an implementation for that filter.

39
00:03:49,560 --> 00:03:54,090
We can validate this as well by putting a breakpoint here.

40
00:03:54,240 --> 00:04:01,800
So let's try to go and start our application by going to the main class and selecting debug as Java

41
00:04:01,800 --> 00:04:09,350
application and whatever configurations that we discuss should never be enabled or configured inside

42
00:04:09,390 --> 00:04:10,810
a production application.

43
00:04:10,830 --> 00:04:19,529
The reason is this logger's will also print some sensitive information like sectionally tokens and what

44
00:04:19,529 --> 00:04:21,000
are the odds and values?

45
00:04:21,209 --> 00:04:24,380
All such sensitive information will be logged.

46
00:04:24,390 --> 00:04:25,530
Due to that reason.

47
00:04:25,650 --> 00:04:32,190
It is strongly recommended not to make this configuration inside your production applications.

48
00:04:32,190 --> 00:04:38,550
And the same has been printed in the console as well, where Spring security team is saying do not use

49
00:04:38,550 --> 00:04:39,710
in a production system.

50
00:04:40,020 --> 00:04:48,420
So now I clear this Start-Up log, I'll go to my UI, I'll try to perform login operation with the credentials

51
00:04:48,420 --> 00:04:49,020
that I have.

52
00:04:49,290 --> 00:04:50,850
Authentication is successful.

53
00:04:51,000 --> 00:04:57,090
Let's try to go to the back and console and see what information might springboard application printer

54
00:04:57,090 --> 00:04:57,810
and the console.

55
00:04:57,960 --> 00:04:59,820
You can see here there is a lot of.

56
00:04:59,880 --> 00:05:06,780
Security and sensitive information that it has logged along with your authorization, that which includes

57
00:05:06,780 --> 00:05:12,330
your username and password, which is very danger to enable in the protection system, and at the same

58
00:05:12,330 --> 00:05:20,990
time, it also logged what are the current security filter chain that has been configured for our application?

59
00:05:21,240 --> 00:05:28,510
And you can see all these filters will be executed one by one in this order defined here.

60
00:05:28,830 --> 00:05:35,370
That means the very first filter that will execute is this one followed by security context, persistent

61
00:05:35,370 --> 00:05:38,060
filter to the end of the filter chain.

62
00:05:38,250 --> 00:05:45,900
And you can see these two filters got added to the chain because we made configurations related to cards

63
00:05:45,900 --> 00:05:48,390
and Casares inside our application.

64
00:05:48,570 --> 00:05:53,240
And at the same time, basic authentication filter will be added to the filter chain.

65
00:05:53,250 --> 00:05:58,950
Whenever we try to perform authentication and authorization using user name and credentials by making

66
00:05:58,950 --> 00:06:01,590
a configuration of it should be basic.

67
00:06:01,590 --> 00:06:05,800
Our form login inside our projects bring security configuration.

68
00:06:06,060 --> 00:06:13,140
So now we are clear what all the internal filters maintained by spring security based upon the configurations

69
00:06:13,140 --> 00:06:20,520
that we make and how to validate them by making some changes to our logger's inside our application.

70
00:06:20,670 --> 00:06:27,570
Let's try to validate the same one more time by keeping a breakpoint in this matter to filter present

71
00:06:27,570 --> 00:06:33,820
inside the glass virtual filtered chain, which is an inner class inside the chain proxy.

72
00:06:33,930 --> 00:06:40,800
I will try to invoke an operation and you can see here these additional filters will have all the filters

73
00:06:40,800 --> 00:06:46,110
configured by the spring security framework based upon the configurations that we make.

74
00:06:46,290 --> 00:06:52,890
So these are all the filters that has been configured and every filter has its own order, which we

75
00:06:52,890 --> 00:06:54,610
call it as a position as well.

76
00:06:54,630 --> 00:07:02,580
And after invoking of a filter, the current operation will be incremental to call the next to filter

77
00:07:02,580 --> 00:07:10,170
in the chain by fetching it from the additional filters list and invoking that filter method implementation

78
00:07:10,170 --> 00:07:11,610
from that specific filter.

79
00:07:11,910 --> 00:07:20,340
So in this way, spring security will leverage all the filters configured inside our application one

80
00:07:20,340 --> 00:07:22,410
by one in a chain manner.

81
00:07:22,710 --> 00:07:27,750
So now we have a clear understanding on that in the spring security filters.

82
00:07:28,200 --> 00:07:37,230
In the next video, let's try to understand how to write our own custom filter to address our own application

83
00:07:37,260 --> 00:07:38,400
business requirements.

84
00:07:38,580 --> 00:07:39,050
Thank you.

85
00:07:39,060 --> 00:07:40,590
And see you in the next video by.