1 00:00:02,320 --> 00:00:06,850 So at this point, we did now add user login. 2 00:00:06,850 --> 00:00:10,590 We are checking that email and password provided by the user 3 00:00:10,590 --> 00:00:14,570 to see whether we find that data in our database. 4 00:00:14,570 --> 00:00:17,940 But right now, of course it still makes no difference 5 00:00:17,940 --> 00:00:19,720 whether we logged in or not. 6 00:00:19,720 --> 00:00:22,060 We can always reach this admin page, 7 00:00:22,060 --> 00:00:24,290 which for this demo here, 8 00:00:24,290 --> 00:00:26,660 I actually would like to protect 9 00:00:26,660 --> 00:00:28,833 against unauthenticated access. 10 00:00:29,690 --> 00:00:31,810 So how do we get there? 11 00:00:31,810 --> 00:00:35,040 For this, it is really important to understand 12 00:00:35,040 --> 00:00:40,040 that log in is not a feature you just add to your website 13 00:00:40,640 --> 00:00:43,030 and all of a sudden it works the way you want 14 00:00:43,030 --> 00:00:46,950 and all the pages you want to protect are protected. 15 00:00:46,950 --> 00:00:50,400 Instead, adding user login is just one step 16 00:00:50,400 --> 00:00:54,160 of three main steps for authentication 17 00:00:54,160 --> 00:00:57,870 and it's the overall process, adding signup, 18 00:00:57,870 --> 00:01:00,910 adding log in and then, in the third step, 19 00:01:00,910 --> 00:01:04,319 using that login information to protect pages 20 00:01:04,319 --> 00:01:06,790 that will allow you as a developer 21 00:01:06,790 --> 00:01:10,100 to guard certain areas of your website 22 00:01:10,100 --> 00:01:13,020 against unauthenticated access. 23 00:01:13,020 --> 00:01:16,760 So it's not a feature you just drop into your website. 24 00:01:16,760 --> 00:01:18,370 Instead, you as a developer 25 00:01:18,370 --> 00:01:21,380 really have to write the code for the different steps 26 00:01:21,380 --> 00:01:24,770 to make sure that certain areas are not accessible 27 00:01:24,770 --> 00:01:26,890 by certain users. 28 00:01:26,890 --> 00:01:30,380 And we completed the first two steps, 29 00:01:30,380 --> 00:01:34,500 which are now the prerequisites for the major third step, 30 00:01:34,500 --> 00:01:38,040 where we now wanna use the user data we have 31 00:01:38,040 --> 00:01:40,930 and where we wanna use this login step 32 00:01:40,930 --> 00:01:45,850 to finally lock down a certain part of our website 33 00:01:45,850 --> 00:01:49,573 and still grant access to some users who did login. 34 00:01:50,440 --> 00:01:55,320 But how do we lock down a certain part of our website? 35 00:01:55,320 --> 00:01:58,400 Well, for this, we will need to track 36 00:01:58,400 --> 00:02:02,590 the user authentication status, somehow. 37 00:02:02,590 --> 00:02:05,900 Because to the web server, to our backend code, 38 00:02:05,900 --> 00:02:10,270 by default, every incoming request looks quite similar. 39 00:02:10,270 --> 00:02:12,940 Of course, it's coming from a different computer, 40 00:02:12,940 --> 00:02:14,740 a different IP address 41 00:02:14,740 --> 00:02:17,920 but those IP addresses are also dynamic. 42 00:02:17,920 --> 00:02:21,130 For example, you don't always have to same IP address, 43 00:02:21,130 --> 00:02:23,870 so we can't really use that for remembering 44 00:02:23,870 --> 00:02:25,920 who's logged in and who's not. 45 00:02:25,920 --> 00:02:28,830 And therefore in the end, every request looks similar 46 00:02:28,830 --> 00:02:32,090 and by looking at a plain request like this, 47 00:02:32,090 --> 00:02:34,370 we're not able to tell who should be allowed 48 00:02:34,370 --> 00:02:37,893 to access a certain resource and who should not be allowed. 49 00:02:38,760 --> 00:02:40,760 Instead we, as a developer, 50 00:02:40,760 --> 00:02:42,860 will need to implement some kind 51 00:02:42,860 --> 00:02:46,330 of ticketing system, you could say. 52 00:02:46,330 --> 00:02:49,600 If you book a ticket for a flight, 53 00:02:49,600 --> 00:02:54,600 then you get a ticket to your smartphone or via email 54 00:02:54,850 --> 00:02:58,210 and the flight company, the airline, 55 00:02:58,210 --> 00:03:01,720 actually of course also keeps an entry in their database 56 00:03:01,720 --> 00:03:03,870 so that when you come with your ticket 57 00:03:03,870 --> 00:03:06,950 to the airport and you show your ticket there, 58 00:03:06,950 --> 00:03:09,500 you are granted access to the plane. 59 00:03:09,500 --> 00:03:12,330 And of course, that does not just work like this for flights 60 00:03:12,330 --> 00:03:16,110 and planes but basically for all kinds of events. 61 00:03:16,110 --> 00:03:19,170 If you book a ticket for the cinema, 62 00:03:19,170 --> 00:03:20,631 then you also get your ticket 63 00:03:20,631 --> 00:03:23,930 and they also have a copy in their system 64 00:03:23,930 --> 00:03:25,860 with which they could check 65 00:03:25,860 --> 00:03:29,940 if people are showing faked tickets or anything like this. 66 00:03:29,940 --> 00:03:33,020 And now it's the same for web servers. 67 00:03:33,020 --> 00:03:35,920 As a developer, we will have to write code 68 00:03:35,920 --> 00:03:39,810 where we generate some kind of ticket, you could say, 69 00:03:39,810 --> 00:03:43,430 on the server, which we store on the server 70 00:03:43,430 --> 00:03:45,860 in the database, for example. 71 00:03:45,860 --> 00:03:49,600 And where we then also hand out a copy of the ticket 72 00:03:49,600 --> 00:03:53,030 or the ID of the ticket to our user. 73 00:03:53,030 --> 00:03:54,840 So to the browser, in this case, 74 00:03:54,840 --> 00:03:57,870 for the user to store it and to show it to us 75 00:03:57,870 --> 00:04:02,310 when he or she wants to access a protected resource. 76 00:04:02,310 --> 00:04:05,240 That is what we will now need to implement. 77 00:04:05,240 --> 00:04:07,680 So that in our server side code, 78 00:04:07,680 --> 00:04:12,410 in the routes here for the admin route, 79 00:04:12,410 --> 00:04:15,150 for this route here, we could then, for example, 80 00:04:15,150 --> 00:04:19,360 add some code to check the user ticket 81 00:04:19,360 --> 00:04:22,350 and see if the user, if the request who's arriving, 82 00:04:22,350 --> 00:04:24,380 has a valid ticket, 83 00:04:24,380 --> 00:04:27,400 which we also stored in the server side database. 84 00:04:27,400 --> 00:04:29,910 And we only render this admin page 85 00:04:29,910 --> 00:04:33,090 if a valid ticket was shown to us, 86 00:04:33,090 --> 00:04:36,240 otherwise we rendered this 401 template 87 00:04:36,240 --> 00:04:37,740 where we tell the user 88 00:04:37,740 --> 00:04:40,540 that he or she is not authenticated. 89 00:04:40,540 --> 00:04:43,860 That is the final step of authentication, 90 00:04:43,860 --> 00:04:46,360 which we will now need to implement. 91 00:04:46,360 --> 00:04:49,920 And the idea simply is that when a user logs in, 92 00:04:49,920 --> 00:04:52,480 so when that login data is submitted 93 00:04:52,480 --> 00:04:55,180 and then verified on the server, 94 00:04:55,180 --> 00:04:59,370 we generate such a ticket and send that back to the user, 95 00:04:59,370 --> 00:05:02,460 so that the browser of the user is able to store it 96 00:05:02,460 --> 00:05:05,460 and then show it to us in future requests 97 00:05:05,460 --> 00:05:09,440 where access to protected pages is requested. 98 00:05:09,440 --> 00:05:13,010 And here's how this process will look like in detail. 99 00:05:13,010 --> 00:05:17,000 We're going to leverage a feature called sessions, 100 00:05:17,000 --> 00:05:20,340 which is not a feature exclusively available 101 00:05:20,340 --> 00:05:22,580 for authentication purposes, 102 00:05:22,580 --> 00:05:24,700 as I will show you in this session 103 00:05:24,700 --> 00:05:26,960 but which we typically do leverage 104 00:05:26,960 --> 00:05:29,190 for authentication purposes. 105 00:05:29,190 --> 00:05:32,340 Because sessions will be these tickets 106 00:05:32,340 --> 00:05:34,600 that we generate on the server. 107 00:05:34,600 --> 00:05:37,750 But here's how the overall process will look like. 108 00:05:37,750 --> 00:05:41,020 We got the various involved parties, the client, 109 00:05:41,020 --> 00:05:44,040 so the user using a browser, our server 110 00:05:44,040 --> 00:05:46,050 and then probably some database 111 00:05:46,050 --> 00:05:49,610 or some other data storage like us storing data 112 00:05:49,610 --> 00:05:50,530 in some files. 113 00:05:50,530 --> 00:05:53,340 So some data storage which we access on the backend 114 00:05:53,340 --> 00:05:56,220 and all these processes are talking to each other 115 00:05:56,220 --> 00:05:58,323 as we learned it throughout this course. 116 00:05:59,480 --> 00:06:02,370 Now a user wants to log into our website 117 00:06:02,370 --> 00:06:06,350 and then in the future, access protected resources. 118 00:06:06,350 --> 00:06:09,407 For this, the user sends us the login credentials 119 00:06:09,407 --> 00:06:13,120 and on the server, we then validate those credentials. 120 00:06:13,120 --> 00:06:15,080 These are the steps we implemented 121 00:06:15,080 --> 00:06:17,150 in the last lectures already. 122 00:06:17,150 --> 00:06:21,780 We are able to get the login data and verify it 123 00:06:21,780 --> 00:06:23,510 but now we'll reach the new steps 124 00:06:23,510 --> 00:06:26,230 which we have yet to implement. 125 00:06:26,230 --> 00:06:30,640 Once we've validated and confirmed the user credentials 126 00:06:30,640 --> 00:06:33,730 on the server, we will generate such a ticket, 127 00:06:33,730 --> 00:06:37,900 a so-called session, which is just a piece of data, 128 00:06:37,900 --> 00:06:41,300 a record or a document for our database in the end, 129 00:06:41,300 --> 00:06:44,170 which we will insert in the database. 130 00:06:44,170 --> 00:06:46,560 And we don't need a database necessarily, 131 00:06:46,560 --> 00:06:47,860 it's just a piece of data 132 00:06:47,860 --> 00:06:50,370 which we need to store somewhere. 133 00:06:50,370 --> 00:06:53,710 We could even store it in memory on the server 134 00:06:53,710 --> 00:06:56,190 but there, it would, for example, be lost 135 00:06:56,190 --> 00:06:58,360 if the server restarts. 136 00:06:58,360 --> 00:07:03,130 We could store it in a file or as shown here, in a database. 137 00:07:03,130 --> 00:07:05,320 So it's a record, a document, 138 00:07:05,320 --> 00:07:09,820 with only a few pieces of relatively trivial data 139 00:07:09,820 --> 00:07:12,490 that will be stored in the database. 140 00:07:12,490 --> 00:07:16,650 Most importantly, such a session record or document 141 00:07:16,650 --> 00:07:19,050 will have a unique ID. 142 00:07:19,050 --> 00:07:21,970 Every session will have its own unique ID 143 00:07:21,970 --> 00:07:25,070 and whilst we will be able to use this session feature 144 00:07:25,070 --> 00:07:26,910 for all kinds of things, 145 00:07:26,910 --> 00:07:31,910 we can also use it to store information that a certain user 146 00:07:32,200 --> 00:07:35,323 should be granted access to certain resources. 147 00:07:36,410 --> 00:07:38,630 Because that's the important thing. 148 00:07:38,630 --> 00:07:42,250 Every session will be unique per user, 149 00:07:42,250 --> 00:07:44,950 so every visitor of our website 150 00:07:44,950 --> 00:07:48,170 will receive his or her own session. 151 00:07:48,170 --> 00:07:52,220 And actually, that session can and in reality, 152 00:07:52,220 --> 00:07:54,580 often will already be created 153 00:07:54,580 --> 00:07:57,040 before the user even logged in 154 00:07:57,040 --> 00:07:59,180 but before the user logged in, 155 00:07:59,180 --> 00:08:01,270 we will simply store the information 156 00:08:01,270 --> 00:08:05,460 that this user hasn't logged in yet in the session. 157 00:08:05,460 --> 00:08:08,280 But then we will still have a session for this user 158 00:08:08,280 --> 00:08:10,930 and we can map a session to a user 159 00:08:10,930 --> 00:08:15,190 because the server will send back the session ID 160 00:08:15,190 --> 00:08:18,310 to the client, so to the user. 161 00:08:18,310 --> 00:08:21,758 And there, it will be stored in a so-called cookie. 162 00:08:21,758 --> 00:08:22,630 (paper crinkles) 163 00:08:22,630 --> 00:08:25,320 So that cookie will be sent back to the client 164 00:08:25,320 --> 00:08:27,690 and the client will then automatically store 165 00:08:27,690 --> 00:08:29,060 and manage this cookie, 166 00:08:29,060 --> 00:08:31,620 so the browser will do this for us. 167 00:08:31,620 --> 00:08:34,000 And you might've heard about cookies as well. 168 00:08:34,000 --> 00:08:36,049 We all know them from those friendly 169 00:08:36,049 --> 00:08:37,860 and super convenient banners, 170 00:08:37,860 --> 00:08:40,650 which we see on a lot of websites these days. 171 00:08:40,650 --> 00:08:44,010 Cookies can be used for bad or annoying things 172 00:08:44,010 --> 00:08:46,304 like tracking and advertisement 173 00:08:46,304 --> 00:08:49,630 but we can also use them for authentication, 174 00:08:49,630 --> 00:08:52,870 simply to store a session ID in the browser 175 00:08:52,870 --> 00:08:56,320 so that we have the session on the server side in a database 176 00:08:56,320 --> 00:08:58,850 and then the unique ID of the session 177 00:08:58,850 --> 00:09:02,000 and only that, also in the browser. 178 00:09:02,000 --> 00:09:04,750 And why do we need that ID in the browser? 179 00:09:04,750 --> 00:09:06,640 Because once the browser knows 180 00:09:06,640 --> 00:09:09,660 the ID of a session that's stored on the server, 181 00:09:09,660 --> 00:09:14,000 that session ID can be sent with subsequent requests 182 00:09:14,000 --> 00:09:17,660 to the server and therefore then the server knows 183 00:09:17,660 --> 00:09:20,400 that this request is coming from the client 184 00:09:20,400 --> 00:09:22,400 with a certain session ID. 185 00:09:22,400 --> 00:09:25,650 The server is then able to look for this session ID 186 00:09:25,650 --> 00:09:28,480 in the database and then extract any data 187 00:09:28,480 --> 00:09:31,490 that might've been stored for this specific client 188 00:09:31,490 --> 00:09:32,980 in that session. 189 00:09:32,980 --> 00:09:35,800 And there can be all kinds of data. 190 00:09:35,800 --> 00:09:39,210 We could store a shopping cart in such a session. 191 00:09:39,210 --> 00:09:40,130 And as I mentioned, 192 00:09:40,130 --> 00:09:41,980 you don't even have to be authenticated 193 00:09:41,980 --> 00:09:43,730 for this feature to exist 194 00:09:43,730 --> 00:09:46,540 because we can create such a session with a unique ID 195 00:09:46,540 --> 00:09:49,010 and send that ID back to a client, 196 00:09:49,010 --> 00:09:51,740 no matter if that client logged in or not. 197 00:09:51,740 --> 00:09:56,660 But that session can also contain a flag or a piece of data 198 00:09:56,660 --> 00:10:01,560 that says this client with this unique ID is authenticated. 199 00:10:01,560 --> 00:10:05,110 And that's then what we can look for to grant access 200 00:10:05,110 --> 00:10:07,330 to protected resources. 201 00:10:07,330 --> 00:10:09,120 That's the big picture. 202 00:10:09,120 --> 00:10:11,070 Now, before we implement all of that 203 00:10:11,070 --> 00:10:14,150 and go through this process step-by-step, 204 00:10:14,150 --> 00:10:17,700 let's take another closer look at sessions and cookies, 205 00:10:17,700 --> 00:10:21,100 which are two key concepts in web development. 206 00:10:21,100 --> 00:10:23,200 And here it's important to understand 207 00:10:23,200 --> 00:10:25,460 and to keep in mind that sessions 208 00:10:25,460 --> 00:10:27,340 are a server side construct, 209 00:10:27,340 --> 00:10:29,660 which are stored on the server side, 210 00:10:29,660 --> 00:10:31,470 for example, in a database 211 00:10:31,470 --> 00:10:34,480 and cookies are stored on the client side, 212 00:10:34,480 --> 00:10:36,600 and there are different kinds of cookies. 213 00:10:36,600 --> 00:10:38,670 As I mentioned, also for tracking 214 00:10:38,670 --> 00:10:41,380 or advertisement but session cookies, 215 00:10:41,380 --> 00:10:43,490 so that store the ID of a session, 216 00:10:43,490 --> 00:10:47,290 are one of the more useful use cases for cookies, 217 00:10:47,290 --> 00:10:50,120 one of the less annoying use cases, so to say, 218 00:10:50,120 --> 00:10:52,980 because these session cookies are crucial 219 00:10:52,980 --> 00:10:57,980 for mapping a client to a certain session on the database. 220 00:10:58,100 --> 00:11:01,740 And unlike the IP address of a client, for example, 221 00:11:01,740 --> 00:11:05,440 which often is dynamic and changes on a daily basis 222 00:11:05,440 --> 00:11:08,760 or even more frequently, the session cookie 223 00:11:08,760 --> 00:11:13,010 is a long lived cookie which doesn't change randomly. 224 00:11:13,010 --> 00:11:15,950 So the session ID the server sent back to a client 225 00:11:15,950 --> 00:11:18,690 does not change all the time, instead it's fixed 226 00:11:18,690 --> 00:11:22,290 and that cookie can be stored in the browser for days, 227 00:11:22,290 --> 00:11:24,863 weeks, months, or even years. 228 00:11:25,910 --> 00:11:28,140 But it is worth knowing that sessions and cookies 229 00:11:28,140 --> 00:11:30,970 are not exclusively used for authentication. 230 00:11:30,970 --> 00:11:34,240 I mentioned that cookies can be used for tracking and so on 231 00:11:34,240 --> 00:11:36,840 and I will show you another use case for sessions 232 00:11:36,840 --> 00:11:38,760 in this course section, 233 00:11:38,760 --> 00:11:41,340 because sessions, as I emphasized before 234 00:11:41,340 --> 00:11:43,240 and as I wanna emphasize again, 235 00:11:43,240 --> 00:11:46,040 are not authentication-exclusive. 236 00:11:46,040 --> 00:11:48,030 Instead, unauthenticated users 237 00:11:48,030 --> 00:11:50,340 can and will also receive sessions 238 00:11:50,340 --> 00:11:53,000 since you can store all kinds of data in them 239 00:11:53,000 --> 00:11:56,140 and the flag that a certain user is authenticated 240 00:11:56,140 --> 00:11:59,680 is just one possible piece of data you can store in there. 241 00:11:59,680 --> 00:12:01,570 So it really comes down to which data 242 00:12:01,570 --> 00:12:02,910 you store in a session 243 00:12:02,910 --> 00:12:05,990 and you can then do all kinds of things with that data, 244 00:12:05,990 --> 00:12:08,410 as you will see in this section. 245 00:12:08,410 --> 00:12:10,360 And then for cookies, well there, 246 00:12:10,360 --> 00:12:12,080 we got other use cases as well 247 00:12:12,080 --> 00:12:13,700 but a lot of them are annoying 248 00:12:13,700 --> 00:12:16,400 and therefore, we'll focus on the session cookies, 249 00:12:16,400 --> 00:12:18,970 which are very useful and absolutely required 250 00:12:18,970 --> 00:12:20,563 in this course section here.