1
00:00:00,000 --> 00:00:04,746
[MUSIC]

2
00:00:04,746 --> 00:00:08,050
Let's talk in some CORS language now.

3
00:00:08,050 --> 00:00:11,500
Now what exactly is cross
origin results sharing, and

4
00:00:11,500 --> 00:00:15,325
why is it relevant when we
look at web applications and

5
00:00:15,325 --> 00:00:21,010
hyper-mobile applications as we have
been doing in this specialization?

6
00:00:21,010 --> 00:00:25,260
As you understand,
most webpages now pull in data from

7
00:00:25,260 --> 00:00:29,790
many different sites in order
to construct a webpage.

8
00:00:29,790 --> 00:00:38,470
Now, in order to impose a strict policy of
access to resources from different sites,

9
00:00:38,470 --> 00:00:44,220
the same origin policy has
been imposed by many browsers.

10
00:00:44,220 --> 00:00:49,410
We'll talk a little bit about that in
more detail in the next few slides, but

11
00:00:49,410 --> 00:00:55,950
in the context of the frameworks that we
have been discussing in this particular

12
00:00:55,950 --> 00:01:00,640
specialization, like Angular,
Ionic, and NativeScript,

13
00:01:00,640 --> 00:01:05,650
many of these will involve scripts,
JavaScript code,

14
00:01:05,650 --> 00:01:11,220
that might have to access
resources from different sites.

15
00:01:11,220 --> 00:01:16,790
And this is where the CORS
problem crops up very easily.

16
00:01:16,790 --> 00:01:22,290
Let's see how we will address this issue
in more detail in this lecture and

17
00:01:22,290 --> 00:01:24,050
the exercise that follows.

18
00:01:25,940 --> 00:01:31,446
I briefly alluded to the same-origin
policy that I started this lecture.

19
00:01:31,446 --> 00:01:36,510
Now, the same-origin policy
is a web app security model

20
00:01:36,510 --> 00:01:40,170
which restricts how a document or a script

21
00:01:40,170 --> 00:01:45,380
loaded from one origin will interact
with resources from another origin.

22
00:01:45,380 --> 00:01:50,270
The purpose of this is to isolate
potentially malicious documents.

23
00:01:50,270 --> 00:01:54,940
Now obviously, when you have
a webpage that involves script,

24
00:01:54,940 --> 00:02:00,900
JavaScript code, that might access
resources from another location,

25
00:02:00,900 --> 00:02:05,185
potentially malicious code could
be injected into your webpage and

26
00:02:05,185 --> 00:02:12,800
whereby access a different origin than
from where your webpage is obtained.

27
00:02:12,800 --> 00:02:17,220
Now, that is the reason many browsers
impose this same-origin policy.

28
00:02:17,220 --> 00:02:22,230
Now, when we talk about same-origin,
how do we specify an origin?

29
00:02:22,230 --> 00:02:28,540
Now in this context, an origin for
any resource is defined by three tuples.

30
00:02:28,540 --> 00:02:32,980
First, the protocol that is
used to access the resource.

31
00:02:32,980 --> 00:02:39,410
Secondly, the host name of the resource,
or the domain of that resource.

32
00:02:39,410 --> 00:02:43,480
And thirdly, the port number at which
that resource is being accessed.

33
00:02:43,480 --> 00:02:48,700
So this is how we identify
the origin of any resource.

34
00:02:48,700 --> 00:02:53,626
Resource in this case could
be a html page, an image,

35
00:02:53,626 --> 00:03:00,720
JSON data being obtained from
a REST API endpoint, and many more.

36
00:03:00,720 --> 00:03:05,410
To further elaborate on the same-origin
policy, let's look at an example.

37
00:03:05,410 --> 00:03:12,315
Suppose we have a webpage that is
loaded in from this site listed here,

38
00:03:12,315 --> 00:03:17,330
www.abc.com, and in a folder xyz, and

39
00:03:17,330 --> 00:03:21,210
the page.html being loaded in here.

40
00:03:21,210 --> 00:03:26,890
This page may involve links or
even JavaScript code that might

41
00:03:26,890 --> 00:03:33,200
issue XMLHttpRequest to other
resources on the webpage.

42
00:03:33,200 --> 00:03:38,310
Now, in this case,
if we try to access another URL, for

43
00:03:38,310 --> 00:03:42,690
example, the first one listed here,
which obviously you see is

44
00:03:42,690 --> 00:03:47,860
from the same site but
from a different folder.

45
00:03:47,860 --> 00:03:51,820
This is acceptable,
because the origin, in this case,

46
00:03:51,820 --> 00:03:55,420
the protocol being used and
the port number, remains the same.

47
00:03:55,420 --> 00:04:00,660
So, this is acceptable
to access this resource.

48
00:04:00,660 --> 00:04:05,470
Similarly in the second case,
we might have under

49
00:04:07,040 --> 00:04:10,570
several levels of subfolders
a resource that is being accessed.

50
00:04:10,570 --> 00:04:15,850
But again, since their origin remains
the same, which is acceptable.

51
00:04:15,850 --> 00:04:18,260
But let's look at the third example here.

52
00:04:18,260 --> 00:04:23,930
In this example, we see that we
are trying to access a resource here with

53
00:04:23,930 --> 00:04:31,230
the https protocol, which obviously
violates the same-origin principal

54
00:04:31,230 --> 00:04:35,580
because we are using a different protocol
to access that resource at this point.

55
00:04:35,580 --> 00:04:39,030
So that would be considered
a failure in this case.

56
00:04:39,030 --> 00:04:44,840
The fourth case is where we are accessing
a resource with a different port number.

57
00:04:44,840 --> 00:04:50,300
And the fifth case is where we are
accessing a resource at a different host.

58
00:04:50,300 --> 00:04:54,830
Now, all of these three would
be marked as not valid or

59
00:04:54,830 --> 00:04:58,110
cannot be accessed under
that same-origin policy.

60
00:04:58,110 --> 00:05:02,710
So if you impose the same-origin
policy for access from, for example,

61
00:05:02,710 --> 00:05:10,970
your XMLHttpRequest, then the last three
would not be allowed in this case.

62
00:05:10,970 --> 00:05:16,270
But of course, there are many
situations where that site designer

63
00:05:16,270 --> 00:05:22,510
may actually host resources on different
sites, maybe on different domains,

64
00:05:22,510 --> 00:05:27,128
and still be able to pull in the data
in order to construct the webpage or

65
00:05:27,128 --> 00:05:32,120
to make the web application run or
to make the hybrid mobile application run.

66
00:05:32,120 --> 00:05:38,914
So to accommodate these situations,
the cross-origin request

67
00:05:38,914 --> 00:05:44,798
handling is a method that allows
us to access these resources.

68
00:05:44,798 --> 00:05:50,410
So we consider a request
to be a cross-origin

69
00:05:50,410 --> 00:05:56,290
request if you are trying to access
a resource from a different domain,

70
00:05:56,290 --> 00:06:01,240
or at a different port number,
or with a different protocol.

71
00:06:01,240 --> 00:06:06,920
So how do we accommodate situations where
this is a legitimate access to a resource,

72
00:06:06,920 --> 00:06:08,800
but because of the same-origin policy,

73
00:06:08,800 --> 00:06:12,930
your browser will refuse
to load this resource?

74
00:06:12,930 --> 00:06:15,790
Now this is where, as I mentioned,

75
00:06:15,790 --> 00:06:20,220
many browsers will restrict
cross-origin http requests,

76
00:06:20,220 --> 00:06:26,420
especially those that
are initiated by XMLHttpRequest or

77
00:06:26,420 --> 00:06:30,570
the Fetch protocol for fetching data.

78
00:06:30,570 --> 00:06:36,980
These are relevant when we access
these from within our JavaScript code.

79
00:06:36,980 --> 00:06:41,950
So, in those circumstances, it makes
sense to impose the same-origin policy,

80
00:06:41,950 --> 00:06:46,490
but then we should have a way of
working around the situation where

81
00:06:46,490 --> 00:06:49,980
a legitimate request can be issued.

82
00:06:49,980 --> 00:06:52,184
This is where the CORS approach,

83
00:06:52,184 --> 00:06:56,960
the cross-origin resource sharing
approach, comes to our aid.

84
00:06:56,960 --> 00:07:02,021
So this CORS is a mechanism that
enables web servers to perform

85
00:07:02,021 --> 00:07:06,741
cross-domain requests, or
cross-origin requests.

86
00:07:06,741 --> 00:07:10,400
So here the browser and the server

87
00:07:10,400 --> 00:07:14,375
from where you're trying to fix the
resource will interact with each other and

88
00:07:14,375 --> 00:07:20,945
then come to an agreement saying that
this access is acceptable and allowed.

89
00:07:20,945 --> 00:07:23,575
So once the agreement is reached,

90
00:07:23,575 --> 00:07:29,182
then this request can be
allowed by your browser.

91
00:07:29,182 --> 00:07:32,912
So the browser and the server will
interact with each other in order to

92
00:07:32,912 --> 00:07:38,252
determine if this access to this
resource is an acceptable situation.

93
00:07:38,252 --> 00:07:43,672
So this is where a new set of
HTTP headers were introduced

94
00:07:43,672 --> 00:07:49,010
into the HTTP reply messages
coming from the server side.

95
00:07:49,010 --> 00:07:54,580
These headers allow the servers
to describe the set of origins

96
00:07:54,580 --> 00:08:01,690
that are permitted by the server
to be accessed by the browser.

97
00:08:01,690 --> 00:08:06,760
And in turn the browser realizes
that these resource accesses

98
00:08:06,760 --> 00:08:11,405
are acceptable to be allowed,
even though they are violating that

99
00:08:11,405 --> 00:08:16,230
same-origin policy that
we have seen earlier.

100
00:08:16,230 --> 00:08:19,876
So in this case,
we have headers like, for example,

101
00:08:19,876 --> 00:08:24,821
Access-Control-Allow-Origin,
Access-Control-Allow-Credentials,

102
00:08:24,821 --> 00:08:29,780
Access-Control-Allow-Headers,
Access-Control-Allow-Methods, and

103
00:08:29,780 --> 00:08:35,330
a few others that the server uses
to inform the browser, saying that

104
00:08:35,330 --> 00:08:41,190
this is an acceptable way of accessing
the resource from the browser side.

105
00:08:41,190 --> 00:08:46,970
And when the browser sees these incoming
reply message from the server side,

106
00:08:46,970 --> 00:08:52,510
the browser accepts and allows this
cross-origin request to be performed.

107
00:08:52,510 --> 00:08:56,500
Now, this also means that the server
should be set up to be able to

108
00:08:56,500 --> 00:09:01,230
respond with these header fields and

109
00:09:01,230 --> 00:09:06,800
the header information included in the
reply message coming from the server side.

110
00:09:06,800 --> 00:09:11,424
Now, this is where we divide all
the cross-origin requests into

111
00:09:11,424 --> 00:09:13,260
several categories.

112
00:09:13,260 --> 00:09:18,495
We have the first one being
the simple cross-site request.

113
00:09:18,495 --> 00:09:22,780
In simple cross-site requests,
you might be using either the GET or

114
00:09:22,780 --> 00:09:25,410
the POST with the request body.

115
00:09:25,410 --> 00:09:30,180
But when you are using the POST,
your request body should contain

116
00:09:30,180 --> 00:09:34,688
either application/x-www-URLencoded,

117
00:09:34,688 --> 00:09:39,305
or multipart/form-data, or text/plain.

118
00:09:39,305 --> 00:09:44,805
Then it is treated as a simple
cross-site request and

119
00:09:44,805 --> 00:09:47,625
no custom headers will
be allowed in this case.

120
00:09:47,625 --> 00:09:52,955
So in this case, it is acceptable for
the server to inform the client,

121
00:09:52,955 --> 00:09:57,520
saying this is allowed and
the browser should allow such requests.

122
00:09:57,520 --> 00:10:01,700
So, for example, for widely accessed
resources, like, for example,

123
00:10:01,700 --> 00:10:05,830
if you perform a GET request to a server
in order to fetch the data in order to

124
00:10:05,830 --> 00:10:10,580
construct the UI,
then maybe the GET request is acceptable

125
00:10:10,580 --> 00:10:14,400
no matter which origin that
request is originating from.

126
00:10:14,400 --> 00:10:17,350
So in that case,
your server will reply to the client,

127
00:10:17,350 --> 00:10:23,250
saying Access-Conrol-Allow-Origin,
with that wildcard star here,

128
00:10:23,250 --> 00:10:27,830
meaning that any origin that originates
the request is acceptable, and

129
00:10:27,830 --> 00:10:33,540
the browser should allow the request
to be performed to that server.

130
00:10:33,540 --> 00:10:38,020
And now, you can also restrict
the access to the origin.

131
00:10:38,020 --> 00:10:44,440
In this case, you can specifically
say that if the origin is

132
00:10:44,440 --> 00:10:50,090
a particular site, then it is
acceptable to service this request.

133
00:10:50,090 --> 00:10:55,940
So the browser sees that sending requests

134
00:10:55,940 --> 00:11:01,230
with this particular origin site
in the request is acceptable and

135
00:11:01,230 --> 00:11:03,830
we'll allow the cross-origin request.

136
00:11:03,830 --> 00:11:08,790
So you can control the way the origin is

137
00:11:08,790 --> 00:11:12,870
specified in the request message
coming from the client side.

138
00:11:12,870 --> 00:11:17,500
So the server is able to
accept such requests.

139
00:11:17,500 --> 00:11:23,094
Certain other requests would be under
the category of preflighted requests.

140
00:11:23,094 --> 00:11:27,750
In the preflighted request,
you expect that before the client

141
00:11:27,750 --> 00:11:32,380
sends the actual request,
the client will send a preflight request,

142
00:11:32,380 --> 00:11:37,260
meaning that it contacts
the server to obtain

143
00:11:37,260 --> 00:11:41,380
information from the server before
the actual request is issued.

144
00:11:41,380 --> 00:11:46,580
This is specifically the case where
you issue PUT and DELETE requests

145
00:11:46,580 --> 00:11:52,160
because PUT and DELETE requests might
cause changes on the server side.

146
00:11:52,160 --> 00:11:58,100
And so any method that causes side effects
on the server's data, like the PUT and

147
00:11:58,100 --> 00:12:03,538
the DELETE request, are specially mandated
to follow the preflight approach.

148
00:12:03,538 --> 00:12:08,276
In the preflight approach,
the idea is that the client will

149
00:12:08,276 --> 00:12:12,919
first send an HTTP OPTIONS
request to the server side, and

150
00:12:12,919 --> 00:12:19,174
in reply to that OPTIONS request message
from the client side, the server will

151
00:12:19,174 --> 00:12:24,864
respond with the corresponding
Access-Control-Allow-Headers,

152
00:12:24,864 --> 00:12:31,504
Access-Control-Allow-Origin, and
Access-Control-Allow-Credentials

153
00:12:31,504 --> 00:12:36,350
header information in the reply
to an OPTIONS message.

154
00:12:36,350 --> 00:12:42,359
Thereafter, the client will decide whether
it can issue the cross-origin request or

155
00:12:42,359 --> 00:12:48,870
not based upon the response to the OPTIONS
preflight request that the client sent.

156
00:12:48,870 --> 00:12:53,410
So this is where you have to go
through two steps before your request

157
00:12:53,410 --> 00:12:57,205
can be allowed and
serviced by the server side.

158
00:12:58,340 --> 00:13:03,230
A third category of CORS requests would
be what are called credentialed requests,

159
00:13:03,230 --> 00:13:07,900
where you expect the client to
include credentials in the header

160
00:13:07,900 --> 00:13:09,608
of the request message.

161
00:13:09,608 --> 00:13:13,518
So the requests that are accompanied
by cookies, for example, for

162
00:13:13,518 --> 00:13:19,040
recognizing the session on the server
side, or some kind of HTTP Authentication

163
00:13:19,040 --> 00:13:24,440
information in the authorization
header in the request message.

164
00:13:24,440 --> 00:13:27,843
So in this case,
the server needs to respond with

165
00:13:27,843 --> 00:13:32,460
Access-Control-Allow-Credentials: true
to the client side.

166
00:13:32,460 --> 00:13:37,920
So in this case,
the server will respond with this and

167
00:13:37,920 --> 00:13:41,070
then the client will be
allowed to send their

168
00:13:41,070 --> 00:13:45,720
credentials information in the incoming
request from the client side.

169
00:13:45,720 --> 00:13:50,430
Now, in this case, the
Access-Control-Allow-Origin is not allowed

170
00:13:50,430 --> 00:13:56,550
to have the wild card,
the star, in the reply message.

171
00:13:56,550 --> 00:14:00,770
It is expected to explicitly
specify the origin to

172
00:14:00,770 --> 00:14:03,450
which the request can be initiated.

173
00:14:04,500 --> 00:14:08,235
Now, obviously,
we can implement much of the work,

174
00:14:08,235 --> 00:14:13,796
what we need to do on the server side, by
implementing our own middleware if we so

175
00:14:13,796 --> 00:14:19,260
choose to to handle the CORS-related
replies from the server side.

176
00:14:19,260 --> 00:14:23,570
It's very straightforward, as we have seen
in the code that we have implemented.

177
00:14:23,570 --> 00:14:29,140
Of course, that is one way of handling
CORS-related replies from the server side,

178
00:14:29,140 --> 00:14:34,800
but fortunately,
we have a specific CORS NodeModule

179
00:14:34,800 --> 00:14:40,470
that is designed to
handle this very kind of

180
00:14:40,470 --> 00:14:44,920
work that the server needs to do
to meet the CORS requirements.

181
00:14:44,920 --> 00:14:50,790
So the CORS NodeModule allows us to
configure the CORS on the server side,

182
00:14:50,790 --> 00:14:55,810
including specifying origin information
where the credentials would be accepted

183
00:14:55,810 --> 00:15:01,010
and many other piece of information
such that you can configure the server

184
00:15:01,010 --> 00:15:05,630
to be able to handle CORS-related
replies that it needs to give to

185
00:15:05,630 --> 00:15:09,480
the browser in response
to the request message.

186
00:15:09,480 --> 00:15:15,750
To install the CORS NodeModule,
obviously you see npm install cors,

187
00:15:15,750 --> 00:15:22,280
and then configure the CORS middleware
within your express application.

188
00:15:23,430 --> 00:15:28,940
The CORS module itself provides
a very simple way of enabling CORS.

189
00:15:28,940 --> 00:15:35,970
You can simply include app use
CORS with empty brackets, and

190
00:15:35,970 --> 00:15:41,370
that essentially means that you're opening
up your server, and it'll reply with

191
00:15:41,370 --> 00:15:47,180
the Access-Control-Allow-Origin with the
wild card star to every incoming request.

192
00:15:47,180 --> 00:15:51,940
But when you are configuring your server,
you may want more control over that, so

193
00:15:51,940 --> 00:15:57,190
that is where we can specify
additional options for the CORS.

194
00:15:57,190 --> 00:16:02,790
And not only that,
you can impose CORS handling

195
00:16:02,790 --> 00:16:06,810
differently for
different routes within your server side.

196
00:16:06,810 --> 00:16:12,320
So as we will see in the exercise,
we will impose different CORS requirements

197
00:16:12,320 --> 00:16:17,540
on the different routes on our server
side, and this is all configured by using

198
00:16:17,540 --> 00:16:22,690
various configuration options that
the CORS NodeModule supports for us.

199
00:16:22,690 --> 00:16:28,620
So, using the CORS NodeModule, it is
very easy to setup your server to handle

200
00:16:28,620 --> 00:16:34,020
any cross-origin requests coming
in from your client side and

201
00:16:34,020 --> 00:16:39,730
then respond with appropriate header
information to the client side

202
00:16:39,730 --> 00:16:45,310
with appropriate CORS headers in
the reply message from the server side.

203
00:16:45,310 --> 00:16:48,450
With this quick understanding of CORS,

204
00:16:48,450 --> 00:16:54,730
I'm sure you have more questions at this
point than answers from this lecture.

205
00:16:54,730 --> 00:16:58,960
But if you would like to read
a lot more details about CORS,

206
00:16:58,960 --> 00:17:04,050
I have provided you additional
resources in the end of this lesson,

207
00:17:04,050 --> 00:17:06,804
which enable you to read
more about CORS itself.

208
00:17:06,804 --> 00:17:11,553
But from the perspective of this course,
we would like to configure our

209
00:17:11,553 --> 00:17:15,037
express application that
we have been developing so

210
00:17:15,037 --> 00:17:19,150
far to handle CORS-related
matters on the server side.

211
00:17:19,150 --> 00:17:24,941
So moving on to the exercise,
we will install the CORS npm module and

212
00:17:24,941 --> 00:17:30,236
then configure it on various
routes within our extra server.

213
00:17:30,236 --> 00:17:33,629
[MUSIC]