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

2
00:00:04,746 --> 00:00:08,050
Parlons dans un langage CORS maintenant.

3
00:00:08,050 --> 00:00:11,500
Maintenant, qu'est-ce exactement le partage de résultats d'origine croisée, et

4
00:00:11,500 --> 00:00:15,325
pourquoi est-il pertinent lorsque nous examinons les applications Web et les

5
00:00:15,325 --> 00:00:21,010
applications hyper-mobiles comme nous l'avons fait dans cette spécialisation ?

6
00:00:21,010 --> 00:00:25,260
Comme vous le comprenez, la plupart des pages Web extraient maintenant des données de

7
00:00:25,260 --> 00:00:29,790
nombreux sites différents afin de construire une page Web.

8
00:00:29,790 --> 00:00:38,470
Maintenant, afin d'imposer une politique stricte d'accès aux ressources de différents sites,

9
00:00:38,470 --> 00:00:44,220
la même politique d'origine a été imposée par de nombreux navigateurs.

10
00:00:44,220 --> 00:00:49,410
Nous en parlerons un peu plus en détail dans les prochaines diapositives, mais

11
00:00:49,410 --> 00:00:55,950
dans le contexte des frameworks dont nous avons discuté dans cette

12
00:00:55,950 --> 00:01:00,640
spécialisation particulière, comme Angular, Ionic et NativeScript,

13
00:01:00,640 --> 00:01:05,650
beaucoup d'entre eux impliqueront des scripts, du code JavaScript,

14
00:01:05,650 --> 00:01:11,220
qui pourraient devoir accéder aux ressources de différents sites.

15
00:01:11,220 --> 00:01:16,790
Et c'est là que le problème CORS surgit très facilement.

16
00:01:16,790 --> 00:01:22,290
Voyons comment nous allons aborder cette question plus en détail dans cette conférence et

17
00:01:22,290 --> 00:01:24,050
l'exercice qui suit.

18
00:01:25,940 --> 00:01:31,446
J' ai brièvement fait allusion à la politique de même origine que j'ai entamée cette conférence.

19
00:01:31,446 --> 00:01:36,510
Maintenant, la stratégie de même origine est un modèle de sécurité d'application Web

20
00:01:36,510 --> 00:01:40,170
qui limite la façon dont un document ou un script

21
00:01:40,170 --> 00:01:45,380
chargé à partir d'une origine interagira avec les ressources d'une autre origine.

22
00:01:45,380 --> 00:01:50,270
Le but de cette opération est d'isoler les documents potentiellement malveillants.

23
00:01:50,270 --> 00:01:54,940
Maintenant, évidemment, lorsque vous avez une page Web qui implique un script, du

24
00:01:54,940 --> 00:02:00,900
code JavaScript, qui pourrait accéder à des ressources à partir d'un autre emplacement, du

25
00:02:00,900 --> 00:02:05,185
code potentiellement malveillant pourrait être injecté dans votre page Web et ainsi

26
00:02:05,185 --> 00:02:12,800
accéder à une origine différente de celle d'où votre page Web est obtenue.

27
00:02:12,800 --> 00:02:17,220
Maintenant, c'est la raison pour laquelle de nombreux navigateurs imposent cette politique de même origine.

28
00:02:17,220 --> 00:02:22,230
Maintenant, quand nous parlons de même origine, comment pouvons-nous spécifier une origine ?

29
00:02:22,230 --> 00:02:28,540
Maintenant, dans ce contexte, une origine pour n'importe quelle ressource est définie par trois tuples.

30
00:02:28,540 --> 00:02:32,980
Tout d'abord, le protocole utilisé pour accéder à la ressource.

31
00:02:32,980 --> 00:02:39,410
Deuxièmement, le nom d'hôte de la ressource, ou le domaine de cette ressource.

32
00:02:39,410 --> 00:02:43,480
Et troisièmement, le numéro de port auquel cette ressource est accessible.

33
00:02:43,480 --> 00:02:48,700
C' est ainsi que nous identifions l'origine de n'importe quelle ressource. La

34
00:02:48,700 --> 00:02:53,626
ressource dans ce cas pourrait être une page html, une image, des

35
00:02:53,626 --> 00:03:00,720
données JSON obtenues à partir d'un point de terminaison de l'API REST, et bien d'autres encore.

36
00:03:00,720 --> 00:03:05,410
Pour plus de détails sur la politique de même origine, regardons un exemple.

37
00:03:05,410 --> 00:03:12,315
Supposons que nous ayons une page Web qui est chargée à partir de ce site répertorié ici

38
00:03:12,315 --> 00:03:17,330
, www.abc.com, et dans un dossier xyz, et

39
00:03:17,330 --> 00:03:21,210
le page.html étant chargé ici.

40
00:03:21,210 --> 00:03:26,890
Cette page peut impliquer des liens ou même du code JavaScript qui pourraient

41
00:03:26,890 --> 00:03:33,200
émettre XMLHttpRequest vers d'autres ressources sur la page Web.

42
00:03:33,200 --> 00:03:38,310
Maintenant, dans ce cas, si nous essayons d'accéder à une autre URL

43
00:03:38,310 --> 00:03:42,690
, par exemple, la première listée ici, qui évidemment vous voyez

44
00:03:42,690 --> 00:03:47,860
provient du même site mais d'un dossier différent.

45
00:03:47,860 --> 00:03:51,820
Ceci est acceptable, car l'origine, dans ce cas,

46
00:03:51,820 --> 00:03:55,420
le protocole utilisé et le numéro de port, restent les mêmes.

47
00:03:55,420 --> 00:04:00,660
Donc, cela est acceptable pour accéder à cette ressource.

48
00:04:00,660 --> 00:04:05,470
De même, dans le second cas, nous pourrions avoir sous

49
00:04:07,040 --> 00:04:10,570
plusieurs niveaux de sous-dossiers une ressource qui est accessible.

50
00:04:10,570 --> 00:04:15,850
Mais encore une fois, puisque leur origine reste la même, ce qui est acceptable.

51
00:04:15,850 --> 00:04:18,260
Mais regardons le troisième exemple ici.

52
00:04:18,260 --> 00:04:23,930
Dans cet exemple, nous voyons que nous essayons d'accéder à une ressource ici avec

53
00:04:23,930 --> 00:04:31,230
le protocole https, ce qui viole évidemment le principal de même origine

54
00:04:31,230 --> 00:04:35,580
parce que nous utilisons un protocole différent pour accéder à cette ressource à ce stade.

55
00:04:35,580 --> 00:04:39,030
Ce serait donc considéré comme un échec dans ce cas.

56
00:04:39,030 --> 00:04:44,840
Le quatrième cas est où nous accédons à une ressource avec un numéro de port différent.

57
00:04:44,840 --> 00:04:50,300
Et le cinquième cas est où nous accédons à une ressource sur un autre hôte.

58
00:04:50,300 --> 00:04:54,830
Maintenant, tous ces trois seraient marqués comme non valides ou

59
00:04:54,830 --> 00:04:58,110
ne peuvent pas être accessibles sous cette politique de même origine.

60
00:04:58,110 --> 00:05:02,710
Donc, si vous imposez la même stratégie d'origine pour l'accès à partir, par exemple, de

61
00:05:02,710 --> 00:05:10,970
votre XMLHttpRequest, alors les trois derniers ne seraient pas autorisés dans ce cas.

62
00:05:10,970 --> 00:05:16,270
Mais bien sûr, il y a beaucoup de situations où ce concepteur de site

63
00:05:16,270 --> 00:05:22,510
peut réellement héberger des ressources sur différents sites, peut-être sur différents domaines,

64
00:05:22,510 --> 00:05:27,128
et être toujours capable d'extraire les données afin de construire la page Web ou de

65
00:05:27,128 --> 00:05:32,120
faire fonctionner l'application Web ou de faire fonctionner l'application mobile hybride .

66
00:05:32,120 --> 00:05:38,914
Donc, pour tenir compte de ces situations, le

67
00:05:38,914 --> 00:05:44,798
traitement des demandes d'origine croisée est une méthode qui nous permet d'accéder à ces ressources.

68
00:05:44,798 --> 00:05:50,410
Nous considérons donc une demande comme une

69
00:05:50,410 --> 00:05:56,290
demande d'origine croisée si vous essayez d'accéder à une ressource à partir d'un domaine différent,

70
00:05:56,290 --> 00:06:01,240
ou à un numéro de port différent, ou avec un protocole différent.

71
00:06:01,240 --> 00:06:06,920
Alors, comment pouvons-nous tenir compte des situations où il s'agit d'un accès légitime à une ressource,

72
00:06:06,920 --> 00:06:08,800
mais en raison de la politique de même origine,

73
00:06:08,800 --> 00:06:12,930
votre navigateur refusera de charger cette ressource ?

74
00:06:12,930 --> 00:06:15,790
Maintenant, c'est là que, comme je l'ai mentionné, de

75
00:06:15,790 --> 00:06:20,220
nombreux navigateurs vont restreindre les requêtes http d'origine croisée,

76
00:06:20,220 --> 00:06:26,420
en particulier celles qui sont initiées par XMLHttpRequest ou

77
00:06:26,420 --> 00:06:30,570
le protocole Fetch pour récupérer des données.

78
00:06:30,570 --> 00:06:36,980
Ceux-ci sont pertinents lorsque nous y accédons à partir de notre code JavaScript.

79
00:06:36,980 --> 00:06:41,950
Donc, dans ces circonstances, il est logique d'imposer la politique de même origine,

80
00:06:41,950 --> 00:06:46,490
mais alors nous devrions avoir un moyen de contourner la situation où

81
00:06:46,490 --> 00:06:49,980
une demande légitime peut être émise.

82
00:06:49,980 --> 00:06:52,184
C' est là que

83
00:06:52,184 --> 00:06:56,960
nous aidons l'approche CORS, l'approche de partage des ressources entre les origines.

84
00:06:56,960 --> 00:07:02,021
Ce CORS est donc un mécanisme qui permet aux serveurs Web d'effectuer des requêtes

85
00:07:02,021 --> 00:07:06,741
inter-domaines, ou des demandes d'origine croisée.

86
00:07:06,741 --> 00:07:10,400
Donc, ici, le navigateur et le serveur

87
00:07:10,400 --> 00:07:14,375
d'où vous essayez de réparer la ressource interagiront les uns avec les autres

88
00:07:14,375 --> 00:07:20,945
, puis arriveront à un accord disant que cet accès est acceptable et autorisé.

89
00:07:20,945 --> 00:07:23,575
Donc, une fois que l'accord est atteint,

90
00:07:23,575 --> 00:07:29,182
alors cette demande peut être autorisée par votre navigateur.

91
00:07:29,182 --> 00:07:32,912
Ainsi, le navigateur et le serveur interagiront les uns avec les autres afin de

92
00:07:32,912 --> 00:07:38,252
déterminer si cet accès à cette ressource est une situation acceptable.

93
00:07:38,252 --> 00:07:43,672
C' est donc là qu'un nouvel ensemble d'en-têtes HTTP a été

94
00:07:43,672 --> 00:07:49,010
introduit dans les messages de réponse HTTP provenant du côté serveur.

95
00:07:49,010 --> 00:07:54,580
Ces en-têtes permettent aux serveurs de décrire l'ensemble des origines

96
00:07:54,580 --> 00:08:01,690
auxquelles le serveur est autorisé à accéder par le navigateur.

97
00:08:01,690 --> 00:08:06,760
Et à son tour, le navigateur se rend compte que ces accès

98
00:08:06,760 --> 00:08:11,405
aux ressources sont acceptables pour être autorisés, même s'ils violent cette

99
00:08:11,405 --> 00:08:16,230
politique d'origine identique que nous avons vu précédemment.

100
00:08:16,230 --> 00:08:19,876
Donc, dans ce cas, nous avons des en-têtes comme, par exemple,

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, et

103
00:08:29,780 --> 00:08:35,330
quelques autres que le serveur utilise pour informer le navigateur, disant que

104
00:08:35,330 --> 00:08:41,190
c'est un moyen acceptable d'accéder à la ressource du côté du navigateur.

105
00:08:41,190 --> 00:08:46,970
Et lorsque le navigateur voit ces messages de réponse entrants du côté serveur,

106
00:08:46,970 --> 00:08:52,510
le navigateur accepte et permet l'exécution de cette demande d'origine croisée.

107
00:08:52,510 --> 00:08:56,500
Maintenant, cela signifie également que le serveur doit être configuré pour pouvoir

108
00:08:56,500 --> 00:09:01,230
répondre avec ces champs d'en-tête et

109
00:09:01,230 --> 00:09:06,800
les informations d'en-tête incluses dans le message de réponse venant du côté serveur.

110
00:09:06,800 --> 00:09:11,424
Maintenant, c'est là que nous divisons toutes les demandes d'origine croisée en

111
00:09:11,424 --> 00:09:13,260
plusieurs catégories.

112
00:09:13,260 --> 00:09:18,495
Nous avons le premier étant la simple requête inter-site.

113
00:09:18,495 --> 00:09:22,780
Dans les requêtes intersites simples, vous pouvez utiliser le GET ou le

114
00:09:22,780 --> 00:09:25,410
POST avec le corps de la requête.

115
00:09:25,410 --> 00:09:30,180
Mais lorsque vous utilisez le POST, votre corps de requête doit contenir

116
00:09:30,180 --> 00:09:34,688
soit Application/X-WWW-URLENcoded,

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

118
00:09:39,305 --> 00:09:44,805
Ensuite, il est traité comme une simple requête inter-site et

119
00:09:44,805 --> 00:09:47,625
aucun en-tête personnalisé ne sera autorisé dans ce cas.

120
00:09:47,625 --> 00:09:52,955
Donc, dans ce cas, il est acceptable pour le serveur d'informer le client, en

121
00:09:52,955 --> 00:09:57,520
disant que cela est autorisé et le navigateur devrait autoriser de telles requêtes.

122
00:09:57,520 --> 00:10:01,700
Ainsi, par exemple, pour les ressources largement accessibles, comme, par exemple,

123
00:10:01,700 --> 00:10:05,830
si vous effectuez une requête GET à un serveur afin de récupérer les données afin de

124
00:10:05,830 --> 00:10:10,580
construire l'interface utilisateur, alors peut-être que la requête GET est acceptable

125
00:10:10,580 --> 00:10:14,400
quelle que soit l'origine de cette demande.

126
00:10:14,400 --> 00:10:17,350
Donc, dans ce cas, votre serveur répondra au client, en

127
00:10:17,350 --> 00:10:23,250
disant Access-Conrol-Allow-Origin, avec cette étoile générique ici,

128
00:10:23,250 --> 00:10:27,830
ce qui signifie que toute origine de la requête est acceptable, et que

129
00:10:27,830 --> 00:10:33,540
le navigateur devrait autoriser la requête à être effectuée sur ce serveur.

130
00:10:33,540 --> 00:10:38,020
Et maintenant, vous pouvez également restreindre l'accès à l'origine.

131
00:10:38,020 --> 00:10:44,440
Dans ce cas, vous pouvez spécifiquement dire que si l'origine est

132
00:10:44,440 --> 00:10:50,090
un site particulier, alors il est acceptable de traiter cette demande.

133
00:10:50,090 --> 00:10:55,940
Ainsi, le navigateur voit que l'envoi de requêtes

134
00:10:55,940 --> 00:11:01,230
avec ce site d'origine particulier dans la requête est acceptable et

135
00:11:01,230 --> 00:11:03,830
nous allons autoriser la requête d'origine croisée.

136
00:11:03,830 --> 00:11:08,790
Ainsi, vous pouvez contrôler la façon dont l'origine est

137
00:11:08,790 --> 00:11:12,870
spécifiée dans le message de demande venant du côté client.

138
00:11:12,870 --> 00:11:17,500
Ainsi, le serveur est en mesure d'accepter de telles requêtes.

139
00:11:17,500 --> 00:11:23,094
Certaines autres demandes seraient classées dans la catégorie des demandes préréglées.

140
00:11:23,094 --> 00:11:27,750
Dans la requête avancée, vous vous attendez à ce qu'avant que le client

141
00:11:27,750 --> 00:11:32,380
envoie la demande réelle, le client envoie une requête en amont,

142
00:11:32,380 --> 00:11:37,260
ce qui signifie qu'il contacte le serveur pour obtenir des

143
00:11:37,260 --> 00:11:41,380
informations du serveur avant que la demande réelle ne soit émise.

144
00:11:41,380 --> 00:11:46,580
C' est spécifiquement le cas où vous émettez des requêtes PUT et DELETE

145
00:11:46,580 --> 00:11:52,160
car les requêtes PUT et DELETE peuvent provoquer des modifications côté serveur.

146
00:11:52,160 --> 00:11:58,100
Et donc toute méthode qui provoque des effets secondaires sur les données du serveur, comme la

147
00:11:58,100 --> 00:12:03,538
requête PUT et DELETE, est spécialement mandatée pour suivre l'approche en amont.

148
00:12:03,538 --> 00:12:08,276
Dans l'approche en amont, l'idée est que le client

149
00:12:08,276 --> 00:12:12,919
enverra d'abord une requête HTTP OPTIONS côté serveur, et

150
00:12:12,919 --> 00:12:19,174
en réponse à ce message de demande OPTIONS du côté client, le serveur

151
00:12:19,174 --> 00:12:24,864
répondra avec les Access-Control-Allow-Headers correspondants,

152
00:12:24,864 --> 00:12:31,504
Access-Control-Allow-Origin, et les

153
00:12:31,504 --> 00:12:36,350
informations d'en-tête Access-Control-Allow-Credentials dans la réponse à un message OPTIONS. Par la

154
00:12:36,350 --> 00:12:42,359
suite, le client décidera s'il peut émettre la demande d'origine croisée ou

155
00:12:42,359 --> 00:12:48,870
non en fonction de la réponse à la demande de prévol OPTIONS envoyée par le client.

156
00:12:48,870 --> 00:12:53,410
C' est donc là que vous devez passer par deux étapes avant que votre demande

157
00:12:53,410 --> 00:12:57,205
puisse être autorisée et gérée par le côté serveur.

158
00:12:58,340 --> 00:13:03,230
Une troisième catégorie de demandes CORS serait ce qu'on appelle les demandes d'informations d'identification,

159
00:13:03,230 --> 00:13:07,900
où vous attendez que le client inclue des informations d'identification dans l'en-tête

160
00:13:07,900 --> 00:13:09,608
du message de demande.

161
00:13:09,608 --> 00:13:13,518
Ainsi, les demandes qui sont accompagnées de cookies, par exemple, pour

162
00:13:13,518 --> 00:13:19,040
reconnaître la session sur le côté serveur, ou une sorte d'

163
00:13:19,040 --> 00:13:24,440
informations d'authentification HTTP dans l'en-tête d'autorisation dans le message de demande.

164
00:13:24,440 --> 00:13:27,843
Donc, dans ce cas, le serveur doit répondre avec

165
00:13:27,843 --> 00:13:32,460
Access-Control-Allow-Credentials : true pour le côté client.

166
00:13:32,460 --> 00:13:37,920
Donc, dans ce cas, le serveur répondra avec ceci et

167
00:13:37,920 --> 00:13:41,070
le client sera autorisé à envoyer ses

168
00:13:41,070 --> 00:13:45,720
informations d'identification dans la requête entrante du côté client.

169
00:13:45,720 --> 00:13:50,430
Maintenant, dans ce cas, l'Access-Control-Allow-Origin n'est pas autorisé

170
00:13:50,430 --> 00:13:56,550
à avoir le caractère générique, l'étoile, dans le message de réponse.

171
00:13:56,550 --> 00:14:00,770
Il est prévu de spécifier explicitement l'origine vers

172
00:14:00,770 --> 00:14:03,450
laquelle la demande peut être lancée.

173
00:14:04,500 --> 00:14:08,235
Maintenant, évidemment, nous pouvons implémenter une grande partie du travail,

174
00:14:08,235 --> 00:14:13,796
ce que nous devons faire du côté serveur, en implémentant notre propre middleware si nous

175
00:14:13,796 --> 00:14:19,260
choisissons de gérer les réponses liées au CORS du côté serveur.

176
00:14:19,260 --> 00:14:23,570
C' est très simple, comme nous l'avons vu dans le code que nous avons implémenté.

177
00:14:23,570 --> 00:14:29,140
Bien sûr, c'est une façon de gérer les réponses liées au CORS du côté serveur,

178
00:14:29,140 --> 00:14:34,800
mais heureusement, nous avons un CORS NoDemodule spécifique

179
00:14:34,800 --> 00:14:40,470
qui est conçu pour gérer ce genre de

180
00:14:40,470 --> 00:14:44,920
travail que le serveur doit faire pour répondre aux exigences CORS.

181
00:14:44,920 --> 00:14:50,790
Ainsi, le CORS NoDemodule nous permet de configurer le CORS côté serveur,

182
00:14:50,790 --> 00:14:55,810
y compris en spécifiant les informations d'origine où les informations d'identification seraient acceptées

183
00:14:55,810 --> 00:15:01,010
et beaucoup d'autres informations telles que vous pouvez configurer le serveur

184
00:15:01,010 --> 00:15:05,630
pour pouvoir gérer les réponses liées au CORS qu'il doit donner

185
00:15:05,630 --> 00:15:09,480
au navigateur en réponse au message de demande.

186
00:15:09,480 --> 00:15:15,750
Pour installer CORS NoDemodule, évidemment, vous voyez npm installer cors,

187
00:15:15,750 --> 00:15:22,280
puis configurer le middleware CORS dans votre application express.

188
00:15:23,430 --> 00:15:28,940
Le module CORS lui-même fournit un moyen très simple d'activer CORS.

189
00:15:28,940 --> 00:15:35,970
Vous pouvez simplement inclure l'utilisation de l'application CORS avec des crochets vides,

190
00:15:35,970 --> 00:15:41,370
ce qui signifie essentiellement que vous ouvrez votre serveur, et il répondra avec

191
00:15:41,370 --> 00:15:47,180
l'Access-Control-Allow-Origin avec l'étoile générique à chaque requête entrante.

192
00:15:47,180 --> 00:15:51,940
Mais lorsque vous configurez votre serveur, vous pouvez vouloir plus de contrôle sur cela, de sorte

193
00:15:51,940 --> 00:15:57,190
que nous pouvons spécifier des options supplémentaires pour le CORS.

194
00:15:57,190 --> 00:16:02,790
Et non seulement cela, vous pouvez imposer la gestion CORS

195
00:16:02,790 --> 00:16:06,810
différemment pour différentes routes au sein de votre serveur.

196
00:16:06,810 --> 00:16:12,320
Ainsi, comme nous le verrons dans l'exercice, nous imposerons différentes exigences CORS

197
00:16:12,320 --> 00:16:17,540
sur les différentes routes côté serveur, et tout cela est configuré en utilisant

198
00:16:17,540 --> 00:16:22,690
diverses options de configuration que CORS NoDemodule prend en charge pour nous.

199
00:16:22,690 --> 00:16:28,620
Ainsi, en utilisant CORS NoDemodule, il est très facile de configurer votre serveur pour gérer

200
00:16:28,620 --> 00:16:34,020
toutes les demandes d'origine croisée provenant de votre client

201
00:16:34,020 --> 00:16:39,730
, puis de répondre avec les informations d'en-tête

202
00:16:39,730 --> 00:16:45,310
appropriées côté client avec les en-têtes CORS appropriés dans le message de réponse du côté serveur.

203
00:16:45,310 --> 00:16:48,450
Avec cette compréhension rapide de CORS,

204
00:16:48,450 --> 00:16:54,730
je suis sûr que vous avez plus de questions à ce stade que les réponses de cette conférence.

205
00:16:54,730 --> 00:16:58,960
Mais si vous souhaitez lire beaucoup plus de détails sur CORS,

206
00:16:58,960 --> 00:17:04,050
je vous ai fourni des ressources supplémentaires à la fin de cette leçon,

207
00:17:04,050 --> 00:17:06,804
qui vous permettent d'en savoir plus sur CORS lui-même.

208
00:17:06,804 --> 00:17:11,553
Mais du point de vue de ce cours, nous aimerions configurer notre

209
00:17:11,553 --> 00:17:15,037
application express que nous avons développée jusqu'

210
00:17:15,037 --> 00:17:19,150
à présent pour gérer les questions liées au CORS côté serveur.

211
00:17:19,150 --> 00:17:24,941
Pour passer à l'exercice, nous allons installer le module CORS npm,

212
00:17:24,941 --> 00:17:30,236
puis le configurer sur différentes routes au sein de notre serveur supplémentaire.

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