1
00:00:00,620 --> 00:00:06,050
The previous video, when we are trying to make a communication with the backend server from our white

2
00:00:06,170 --> 00:00:15,170
angular application, we got an error indicating cause coarse means cross origin resource sharing.

3
00:00:15,350 --> 00:00:19,700
That means applications with two different origins.

4
00:00:19,850 --> 00:00:26,660
They're trying to communicate with each other to try to see what is coarse in detail in this video course

5
00:00:26,720 --> 00:00:34,580
is a protocol that enables scripts running on a browser claim to interact with the resources from different

6
00:00:34,580 --> 00:00:41,510
orison, for example, if it Untappd, which is to make an API call, running on a different domain

7
00:00:41,540 --> 00:00:45,840
to different domain can be a different hostname, different board member.

8
00:00:46,160 --> 00:00:53,940
It would be blocked by default due to cost policy in all the processes that we are using today.

9
00:00:54,140 --> 00:01:02,270
So course, as we think it's not a security attack or security issue, it's the default protection provided

10
00:01:02,270 --> 00:01:11,060
by our browsers so that applications which are hosted in two different host are boards are two different

11
00:01:11,060 --> 00:01:14,970
domain names, will be stopped communicating with each other.

12
00:01:14,990 --> 00:01:16,900
So that's a default behavior.

13
00:01:17,120 --> 00:01:24,560
So when we say autism, autism means it can be a Street-Porter history tips and domain name.

14
00:01:24,770 --> 00:01:33,990
And what, if any, services or applications which differ in any of these three parameters like history,

15
00:01:34,380 --> 00:01:42,560
restrictive protocol, domain name or no, they will be treated as cross origin, that these two different

16
00:01:42,560 --> 00:01:45,680
applications are not belongs to the same origin.

17
00:01:45,860 --> 00:01:52,190
Like you've seen the diagram you app, which has a domain name as domain one.

18
00:01:52,460 --> 00:01:56,860
It's trying to consume a service which is hosted on Domain 2.0.

19
00:01:57,080 --> 00:02:06,080
So since this is satisfying cost policy by default, browser will stop the communication between these

20
00:02:06,080 --> 00:02:07,820
two applications.

21
00:02:07,820 --> 00:02:15,050
Indicating that there might be a security breach may happen, but it might be a very valid reason why

22
00:02:15,050 --> 00:02:18,170
two different applications hoster are two different.

23
00:02:18,170 --> 00:02:26,180
Supersport needs to communicate in any application, particularly this is most frequent approach in

24
00:02:26,180 --> 00:02:26,800
Microsoft.

25
00:02:26,810 --> 00:02:34,400
We suspected long back when we are used to build our application in monolithic approach where everything

26
00:02:34,400 --> 00:02:41,180
is deployed into a single server like both your UI pages back and the services, everything stays on

27
00:02:41,180 --> 00:02:45,490
the same post, on same bottom, so that there is no problem of cost.

28
00:02:45,920 --> 00:02:51,410
But these days, when we are building application using Microsoft Services pattern where the services

29
00:02:51,410 --> 00:02:56,840
will be hosted somewhere, your UI application will be hosted somewhere your mobile application will

30
00:02:56,840 --> 00:02:58,170
be hosted in the play store.

31
00:02:58,520 --> 00:03:05,240
So in all the scenarios, there is a good chance cost policy will come into feature and will stop your

32
00:03:05,240 --> 00:03:06,080
communication.

33
00:03:06,350 --> 00:03:13,250
But you have a very valid reason to communicate because all those are your applications and you don't

34
00:03:13,250 --> 00:03:19,220
want the browser to stop that communication due to cost policy to work on the challenge.

35
00:03:19,460 --> 00:03:25,760
Whatever the backend server that is trying to share the data to the UK has to configure it properly

36
00:03:25,910 --> 00:03:30,530
so that cross will be accepted by your browser.

37
00:03:30,740 --> 00:03:38,120
So this can be achieved by making simple configurations on the backend with the following properties.

38
00:03:38,270 --> 00:03:41,840
So one of the properties that you have to set is access control.

39
00:03:42,800 --> 00:03:47,900
So this is the property where you are telling request and response.

40
00:03:47,900 --> 00:03:54,470
Sharing from a particular person has to be shared and no cost restriction should be applied.

41
00:03:54,710 --> 00:04:01,280
Starting to get that means any errors in or any application, any website can communicate with my back.

42
00:04:01,280 --> 00:04:08,510
And so which is not recommended approach always clearly define your horsemen's what name instead of

43
00:04:08,510 --> 00:04:14,810
start and you can also fine grained control like what restrictive methods Castroville look like.

44
00:04:14,810 --> 00:04:19,120
Only get are only post in the course of design request.

45
00:04:19,130 --> 00:04:27,770
We can also define headers credentials and maximum time that this cost policy has to be accepted by

46
00:04:27,770 --> 00:04:30,650
caching the details inside the browser.

47
00:04:30,920 --> 00:04:39,800
So when we define all these details on your server, then your browser since OK, my backend responded

48
00:04:39,950 --> 00:04:46,340
with these details which are related to cause communication and it will start communicating with the

49
00:04:46,340 --> 00:04:49,970
backend server without throwing in cost issue.

50
00:04:50,120 --> 00:04:51,100
So it's very simple.

51
00:04:51,320 --> 00:04:59,600
First, your browser will make a pre-flight request to the back end server whether the policy is allowed

52
00:04:59,600 --> 00:04:59,690
of.

53
00:05:00,120 --> 00:05:05,710
When you're back in server responded with all these parameters, OK, these are the origins that I want,

54
00:05:05,730 --> 00:05:10,510
all of these are the methods, these are the best credentials your browser can understand.

55
00:05:10,570 --> 00:05:18,060
OK, this communication between the U.K. and the backend application is approved by the backend and

56
00:05:18,060 --> 00:05:20,190
it will not throw any cards ever.

57
00:05:20,550 --> 00:05:26,100
So now we have complete clear idea of what is cross origin resource sharing issue.

58
00:05:26,340 --> 00:05:33,240
Let's try to fix this issue using spring security framework and resolve the concern that we are getting

59
00:05:33,510 --> 00:05:34,780
inside the application.

60
00:05:35,100 --> 00:05:42,140
So as you can see, both our applications fall into two different origins because the port name is different.

61
00:05:42,390 --> 00:05:48,030
The upshot that I have for two double zero and the back and forth that I have eight zero eight zero

62
00:05:48,180 --> 00:05:48,950
is different.

63
00:05:49,110 --> 00:05:52,710
That's why my browser is treating them as two different origins.

64
00:05:53,070 --> 00:05:59,340
If I want the communication to happen definitely on the back inside, I have to make configurations

65
00:05:59,520 --> 00:06:07,080
to parse all these parameters so that my browser can pass this communication and will not throw it out.

66
00:06:07,770 --> 00:06:10,050
Let's try to make that change in that mix.

67
00:06:10,060 --> 00:06:10,280
Really.

68
00:06:10,370 --> 00:06:11,130
Thank you by.