Would you like to inspect the original subtitles? These are the user uploaded subtitles that are being translated:
1
00:00:02,160 --> 00:00:05,120
So let's work on logging the user in.
2
00:00:05,120 --> 00:00:07,910
Now, for this I'll keep this signup code
3
00:00:07,910 --> 00:00:09,300
the way it is for the moment
4
00:00:09,300 --> 00:00:12,240
and work on this if part here.
5
00:00:12,240 --> 00:00:13,720
And here we now wanna send
6
00:00:13,720 --> 00:00:18,180
a different HTTP request to a different URL.
7
00:00:18,180 --> 00:00:20,580
To be precise if we have a look at the Firebase
8
00:00:20,580 --> 00:00:22,880
of the rest API documentation,
9
00:00:22,880 --> 00:00:26,380
we now wanna send a request to this sign in
10
00:00:26,380 --> 00:00:31,380
with email and password URL, so this URL here.
11
00:00:31,480 --> 00:00:35,130
And it's still a post request with JSON data,
12
00:00:35,130 --> 00:00:37,160
and the JSON data we do add
13
00:00:37,160 --> 00:00:41,100
actually has the same format as for signing up.
14
00:00:41,100 --> 00:00:44,600
It's just a different URL to which we sent the request
15
00:00:44,600 --> 00:00:47,003
and therefore different things will happen.
16
00:00:48,470 --> 00:00:50,830
Now, since we do have these similarities,
17
00:00:50,830 --> 00:00:53,120
we can share some code though.
18
00:00:53,120 --> 00:00:56,460
Because we'll basically send the request in the same way,
19
00:00:56,460 --> 00:00:59,253
it's just the URL that's different.
20
00:01:00,100 --> 00:01:01,870
And since this is very similar
21
00:01:01,870 --> 00:01:06,160
I'll work with a helper variable, a URL variable,
22
00:01:06,160 --> 00:01:10,070
which we set to the log in URL here,
23
00:01:10,070 --> 00:01:13,030
which I copy and paste it in the login case,
24
00:01:13,030 --> 00:01:16,660
and which we set to this sign up URL here,
25
00:01:16,660 --> 00:01:18,053
in the sign up case.
26
00:01:19,080 --> 00:01:21,080
And for the log in URL,
27
00:01:21,080 --> 00:01:23,790
we also need to add that API key
28
00:01:23,790 --> 00:01:27,070
which we can copy from the sign up URL,
29
00:01:27,070 --> 00:01:31,433
and then use the log in URL as well, like this.
30
00:01:33,920 --> 00:01:35,983
So now I'm just changing the URL.
31
00:01:37,030 --> 00:01:39,680
And we can now grab all that fetch code
32
00:01:39,680 --> 00:01:42,880
and to then block there after and cut that
33
00:01:42,880 --> 00:01:46,270
and move that out of this if else statement
34
00:01:46,270 --> 00:01:48,390
and do that thereafter.
35
00:01:48,390 --> 00:01:50,920
Because again we execute the same logic,
36
00:01:50,920 --> 00:01:52,140
we send this request
37
00:01:52,140 --> 00:01:54,930
and we handle this request in the same way,
38
00:01:54,930 --> 00:01:57,490
at least we can handle it in the same way.
39
00:01:57,490 --> 00:01:59,663
The only thing that differs is the URL.
40
00:02:00,970 --> 00:02:04,600
And therefore I'll remove this hard coded URL
41
00:02:04,600 --> 00:02:05,930
in this fetch function
42
00:02:05,930 --> 00:02:08,979
and use this URL variable instead
43
00:02:08,979 --> 00:02:10,433
which we set before.
44
00:02:11,460 --> 00:02:14,280
And then we send the post request with that data,
45
00:02:14,280 --> 00:02:16,470
which is the same data for logging in,
46
00:02:16,470 --> 00:02:20,010
and signing up as we saw in the documentation.
47
00:02:20,010 --> 00:02:24,550
And we then, well do log in or sign up.
48
00:02:24,550 --> 00:02:29,550
Now we just also wanna handle the success case differently.
49
00:02:30,190 --> 00:02:33,070
Because if logging in succeeds,
50
00:02:33,070 --> 00:02:36,640
we get back a response with this kind of data,
51
00:02:36,640 --> 00:02:39,180
and you see that we get the user email again,
52
00:02:39,180 --> 00:02:44,140
which we logged in and that we also get this ID token.
53
00:02:44,140 --> 00:02:47,410
And that's this authentication token we're interested in
54
00:02:47,410 --> 00:02:49,740
which we then will need in the future
55
00:02:49,740 --> 00:02:54,740
to attach it to our requests to protected resources.
56
00:02:56,290 --> 00:02:58,870
And we also can of course use this ID token
57
00:02:58,870 --> 00:03:01,320
on the front end, in the react app
58
00:03:01,320 --> 00:03:05,440
to use it as proof that this user is logged in
59
00:03:05,440 --> 00:03:07,520
because we only get this token
60
00:03:07,520 --> 00:03:12,520
if a valid email password combination is sent to Firebase.
61
00:03:13,340 --> 00:03:16,140
We can ignore the other data for now.
62
00:03:16,140 --> 00:03:18,530
And we get the same response payload in the end
63
00:03:18,530 --> 00:03:20,040
for signing up.
64
00:03:20,040 --> 00:03:21,610
It's not exactly the same,
65
00:03:21,610 --> 00:03:24,160
but we also get an ID token there.
66
00:03:24,160 --> 00:03:27,170
And that's why we can handle their response in the same way
67
00:03:27,170 --> 00:03:30,103
for both signing up and signing in.
68
00:03:31,610 --> 00:03:33,760
So here if the response is okay,
69
00:03:33,760 --> 00:03:36,880
I then here wanna return response json,
70
00:03:36,880 --> 00:03:40,900
without a nested promise, so not as in the else case,
71
00:03:40,900 --> 00:03:43,540
but just response json.
72
00:03:43,540 --> 00:03:45,650
And on the upper hand here in the else case,
73
00:03:45,650 --> 00:03:49,220
I now wanna throw a new error
74
00:03:50,100 --> 00:03:53,920
with my error message as a message.
75
00:03:53,920 --> 00:03:57,500
And then here after this overall then block,
76
00:03:57,500 --> 00:03:59,190
I wanna add another then block
77
00:03:59,190 --> 00:04:02,200
where I get my response data and the success case
78
00:04:02,200 --> 00:04:05,880
or where I catch any errors we might have,
79
00:04:05,880 --> 00:04:07,940
like the error I'm throwing here
80
00:04:11,250 --> 00:04:15,740
so that I can then copy or cut this alert code
81
00:04:15,740 --> 00:04:17,692
and use that here in the catch block,
82
00:04:18,779 --> 00:04:22,460
to show my error message here.
83
00:04:22,460 --> 00:04:26,260
So now I just restructure this to forward
84
00:04:26,260 --> 00:04:28,370
the error message to this catch block
85
00:04:28,370 --> 00:04:30,340
by throwing an error here,
86
00:04:30,340 --> 00:04:32,050
which will cause this promise
87
00:04:32,050 --> 00:04:35,320
and the other promise to be rejected.
88
00:04:35,320 --> 00:04:36,810
And then we'll make it in here
89
00:04:36,810 --> 00:04:39,340
and we'll make it into this then block here
90
00:04:39,340 --> 00:04:41,663
if we have no error.
91
00:04:43,130 --> 00:04:47,720
So here we'll end up if we have a successful request.
92
00:04:47,720 --> 00:04:51,133
And for the moment I'll just console log that data then.
93
00:04:52,710 --> 00:04:54,400
And with those adjustments made,
94
00:04:54,400 --> 00:04:58,220
we are sharing the logic for a login and sign up
95
00:04:58,220 --> 00:05:01,340
with different URL's though.
96
00:05:01,340 --> 00:05:03,710
And therefore now if I go back.
97
00:05:03,710 --> 00:05:07,580
Let's first of all verify that signing up still works.
98
00:05:07,580 --> 00:05:10,330
If I try to sign up with an email address
99
00:05:10,330 --> 00:05:11,940
that already exists,
100
00:05:11,940 --> 00:05:14,973
I still get my authentication failed error here.
101
00:05:16,200 --> 00:05:18,800
If I switch to log in though here,
102
00:05:18,800 --> 00:05:23,050
and I then log in with let's say invalid credentials,
103
00:05:23,050 --> 00:05:25,150
then I get an error.
104
00:05:25,150 --> 00:05:29,160
If I do log in with valid credentials though
105
00:05:29,160 --> 00:05:31,230
and I clear the console,
106
00:05:31,230 --> 00:05:32,840
you'll see we get no error,
107
00:05:32,840 --> 00:05:35,040
but we get this response object
108
00:05:35,040 --> 00:05:40,040
which has the shape described here in your official docs.
109
00:05:40,120 --> 00:05:43,520
We have a response with these pieces of data
110
00:05:43,520 --> 00:05:45,550
and here you'll also find explanations
111
00:05:45,550 --> 00:05:47,910
of what's in the response.
112
00:05:47,910 --> 00:05:51,530
In the end what matters most to us here is the ID token,
113
00:05:51,530 --> 00:05:54,300
which is this authentication token,
114
00:05:54,300 --> 00:05:57,570
this long string with all that encoded data
115
00:05:57,570 --> 00:06:00,870
that was generated by the Firebase server,
116
00:06:00,870 --> 00:06:03,030
and that can only be verified
117
00:06:03,030 --> 00:06:05,633
by the Firebase server therefore.
118
00:06:07,610 --> 00:06:11,060
And now we know that if we get the this kind of response
119
00:06:11,060 --> 00:06:13,180
with this ID token,
120
00:06:13,180 --> 00:06:16,200
the user did provide valid credentials
121
00:06:16,200 --> 00:06:19,830
because otherwise we would have gotten back an error
122
00:06:19,830 --> 00:06:23,460
and therefore we cannot only use this ID token
123
00:06:23,460 --> 00:06:28,120
to attach it to future requests, to protected resources
124
00:06:28,120 --> 00:06:29,820
but we can also use it as proof
125
00:06:29,820 --> 00:06:31,700
that this user is authenticated
126
00:06:31,700 --> 00:06:34,173
and update this UI accordingly.
9778
Can't find what you're looking for?
Get subtitles in any language from opensubtitles.com, and translate them here.