1 00:00:00,640 --> 00:00:03,620 In the last section we finished deploying our application to Heroku. 2 00:00:03,640 --> 00:00:10,090 But when we tried to test out the overflow we got another nasty redirect you or I mismatched mess message. 3 00:00:10,150 --> 00:00:12,490 So remember we've seen this message in the past. 4 00:00:12,490 --> 00:00:18,550 It means that wherever we are trying to redirect our user to after they go into our waterflow is not 5 00:00:18,550 --> 00:00:21,970 white listed as a valid callback address. 6 00:00:21,970 --> 00:00:27,370 Now this is kind of confusing because we literally just configure that address two seconds ago on the 7 00:00:27,370 --> 00:00:29,290 Google API manager over here. 8 00:00:29,290 --> 00:00:31,110 And so hey here's the address right here. 9 00:00:31,210 --> 00:00:35,270 Looks an awful lot like the one we are trying to redirect the user to right here. 10 00:00:35,590 --> 00:00:41,080 But if you look very closely you'll notice that the redirect you or I that Google thinks that we are 11 00:00:41,080 --> 00:00:49,900 trying to send the user to is P adj I'll buy you at her good outcome blah blah blah but over in our 12 00:00:49,960 --> 00:00:55,480 authorized redirect you or I we specify that address as age TTP s. 13 00:00:55,780 --> 00:01:03,040 So clearly at some point in time something here is breaking and reverting back to age TTP rather than 14 00:01:03,040 --> 00:01:10,510 age to us now for everything that we ever do inside of our application that is tied to authentication. 15 00:01:10,510 --> 00:01:17,500 We always want to use HTP us wherever possible because we are in theory handling some sensitive or authorized 16 00:01:17,500 --> 00:01:23,020 data that we don't want to accidentally make available or leak out to other people who are inspecting 17 00:01:23,020 --> 00:01:24,380 our traffic. 18 00:01:24,400 --> 00:01:28,580 So we want to somehow figure out what's going on here and figure out how to fix it. 19 00:01:30,750 --> 00:01:32,400 So the cause of this problem right here. 20 00:01:32,400 --> 00:01:36,390 We're going to kind of jump to the you know jump to the conclusion here because it's kind of hard to 21 00:01:36,390 --> 00:01:37,620 lead him too nicely. 22 00:01:37,740 --> 00:01:43,810 Essentially this HTP is being generated by a combination of two different factors. 23 00:01:44,010 --> 00:01:48,150 So I can assure you the two factors I'm going to tell you about two different solutions that we can 24 00:01:48,150 --> 00:01:49,110 possible use. 25 00:01:49,290 --> 00:01:51,040 And then we'll go ahead and fix this thing up. 26 00:01:51,150 --> 00:01:51,520 OK. 27 00:01:51,570 --> 00:01:53,010 So let's get to it. 28 00:01:53,790 --> 00:02:00,840 So factor number one that is causing that link to revert back to age TTP and not use the age teach us 29 00:02:00,840 --> 00:02:06,160 that we would hope that it would use is located inside of our services passports. 30 00:02:06,330 --> 00:02:07,060 File. 31 00:02:07,590 --> 00:02:12,060 So inside of this file right here I'm going to scroll down and find my Google strategy. 32 00:02:12,060 --> 00:02:17,650 So here's the Google strategy right here inside of the initial configuration object that we passed in. 33 00:02:17,760 --> 00:02:25,050 We specified a callback u r l that uses a relative path a relative path. 34 00:02:25,050 --> 00:02:32,790 Now the fact that it's relative right here is issue number one that causes the HGT P.S. to drop out 35 00:02:32,790 --> 00:02:38,220 of the address right here or at least make google think that we are trying to send a user back to an 36 00:02:38,220 --> 00:02:44,000 HTP address when we only provide in a relative path right here. 37 00:02:44,100 --> 00:02:48,470 It allows us greater flexibility as we develop and deploy our application. 38 00:02:48,480 --> 00:02:53,640 So as you and I work on our application on both the development environment and then later push it up 39 00:02:53,640 --> 00:02:59,820 to production we can use this callback you RL that uses a relative path right here to not really have 40 00:02:59,820 --> 00:03:06,330 to worry about the different actual callback you are all domains that we want to send our users to think 41 00:03:06,330 --> 00:03:09,430 about it when we are running our code in development. 42 00:03:09,510 --> 00:03:11,700 We want the real true callback. 43 00:03:11,700 --> 00:03:15,240 You are able to be localhost Kolin 5000. 44 00:03:15,420 --> 00:03:16,070 Right. 45 00:03:16,320 --> 00:03:24,110 But when we are in development we want it to be whatever my address is by use something at Heroku app 46 00:03:24,240 --> 00:03:26,980 dot com slash whatever. 47 00:03:27,000 --> 00:03:32,220 So by using the relative callback you are l it means we don't have to really worry about what domain 48 00:03:32,580 --> 00:03:35,970 we are going to try to send the user back to IN THE END. 49 00:03:35,970 --> 00:03:42,010 It is the Google strategy itself that is going to do a little bit of magic to figure out what domain 50 00:03:42,010 --> 00:03:43,100 to put on here. 51 00:03:43,140 --> 00:03:49,040 So it is the Google strategy right now that is deciding what domain to append to the request. 52 00:03:49,080 --> 00:03:54,480 So clearly the real culprit here the real place where everything is going wrong is actually inside of 53 00:03:54,480 --> 00:03:57,710 the Google strategy inside of our developer environment. 54 00:03:57,750 --> 00:04:03,660 It is depending on the correct domain to this callback you IRL but in production it is doing the wrong 55 00:04:03,660 --> 00:04:04,220 thing. 56 00:04:04,440 --> 00:04:06,340 So again that is factor number one. 57 00:04:06,370 --> 00:04:09,710 That's number one thing that is causing things to go wrong here. 58 00:04:09,930 --> 00:04:15,160 Now by default the Google strategy actually does things more or less correctly. 59 00:04:15,180 --> 00:04:16,560 It kind of does things the right way. 60 00:04:16,560 --> 00:04:18,900 It is well written so to speak. 61 00:04:18,930 --> 00:04:23,130 The reason that is doing things incorrectly is because of the second factor. 62 00:04:23,130 --> 00:04:28,410 The other thing that is kind of going wrong with the way our application is deployed. 63 00:04:28,410 --> 00:04:34,230 So this other factor I can't tell you right now this is a very extremely deeply complex topic and I 64 00:04:34,230 --> 00:04:39,890 was going to give you a little bit of a taste on exactly why the Google strategy is doing things incorrectly 65 00:04:41,420 --> 00:04:43,920 set up a diagram. 66 00:04:43,920 --> 00:04:49,890 So this is a diagram of what happens when ever our browser makes a request to our server running on 67 00:04:49,910 --> 00:04:51,170 Hoku servers. 68 00:04:51,210 --> 00:04:54,900 So this would be like our server at Heroku. 69 00:04:55,050 --> 00:05:02,130 So when you and I deploy our application over to Trochu it is running internally on Heroku network which 70 00:05:02,130 --> 00:05:06,840 to be fair is actually hosted on AWOS but that's not really relevant right now. 71 00:05:06,840 --> 00:05:13,560 When we deploy our server it is running on some like very far away hit in virtual machine that is running 72 00:05:13,560 --> 00:05:17,450 along with many other servers at the same time as well. 73 00:05:17,940 --> 00:05:24,480 In order to make sure that traffic from our browser is routed to the correct server Heroku uses a proxy 74 00:05:24,510 --> 00:05:30,630 or a load balancer really its a proxy to make sure that traffic from our browser is routed to the correct 75 00:05:30,630 --> 00:05:32,940 server on its internal network. 76 00:05:32,940 --> 00:05:34,340 Now the issue here. 77 00:05:34,410 --> 00:05:38,850 The reason that like the whole second problem here the reason the Google strategy is calculated that 78 00:05:38,850 --> 00:05:46,920 Domingue incorrectly is that by default the the strategy assumes that if our request from the browser 79 00:05:47,010 --> 00:05:54,390 ever went through any type of proxy then the request should no longer be age to us because it inherently 80 00:05:54,390 --> 00:05:58,990 does not want to trust requests that come through a proxy. 81 00:05:59,040 --> 00:06:04,860 Now in our case we are completely fine trusting the Heroku proxy here like our application is being 82 00:06:04,860 --> 00:06:06,210 hosted on Roku. 83 00:06:06,450 --> 00:06:12,810 Yes we really are OK with the security provided by Heroku and it is completely okay to trust in the 84 00:06:12,810 --> 00:06:14,270 Heroku proxy. 85 00:06:14,280 --> 00:06:21,120 So essentially what we have to do as one possible solution is add one configuration option to our Google 86 00:06:21,120 --> 00:06:28,290 strategy to tell it to trust any proxies that the browser encounters between our server and the original 87 00:06:28,290 --> 00:06:29,040 request. 88 00:06:29,430 --> 00:06:32,900 Again we're not going super deep into like the real technical details here. 89 00:06:32,910 --> 00:06:37,470 I really just want to give you a taste of kind of what's going on rather than saying oh yeah I was going 90 00:06:37,470 --> 00:06:40,610 to use a little setting and say like OK it's fixed. 91 00:06:40,610 --> 00:06:45,990 So that is one possible solution we can add one more setting to the Google strategy. 92 00:06:45,990 --> 00:06:51,660 The other possible solution is to just spell out the entire callback you are l right here. 93 00:06:51,660 --> 00:06:58,380 So rather than passing in just the relative path we could provide the fully qualified path like so. 94 00:06:58,380 --> 00:07:02,510 So the entire thing for development would be like that. 95 00:07:02,610 --> 00:07:06,030 And then for production we could spell out HTP Yes. 96 00:07:06,240 --> 00:07:13,440 And then you know by you or whatever got her through app dot com so we can go either direction one way 97 00:07:13,440 --> 00:07:14,400 or the other. 98 00:07:14,400 --> 00:07:20,730 Now for me I think that life is a little bit easier to just use the relative path right here and not 99 00:07:20,730 --> 00:07:27,750 have to do some runtime decision on whether or not we want to use the local host domain or this one 100 00:07:27,750 --> 00:07:28,600 right here. 101 00:07:28,980 --> 00:07:34,170 So for me I'm going to choose to go with this solution where we pass an additional option to the Google 102 00:07:34,170 --> 00:07:39,660 strategy but we also could have very easily done something where we figure out the domain on the fly 103 00:07:40,140 --> 00:07:45,270 and just in case you're curious we would have just very easily done it probably by adding another little 104 00:07:45,450 --> 00:07:49,620 key to one of our production or development key files. 105 00:07:49,890 --> 00:07:57,000 So we could have easily said inside of one of these like oh yeah Google redirects you or I and then 106 00:07:57,000 --> 00:08:04,170 passed in say a CPS by you Heroku at dot com and all that kind of stuff. 107 00:08:04,170 --> 00:08:08,100 So just as an example like hey it's really pretty easy either way. 108 00:08:08,100 --> 00:08:10,230 I'm just going to go with one direction that is. 109 00:08:10,230 --> 00:08:12,550 I feel like slightly easier. 110 00:08:12,580 --> 00:08:15,740 OK so now I clean this thing back up make sure it only says off. 111 00:08:15,780 --> 00:08:22,200 Slash Google slash callback and then the second option that we want to put in here that I kind of do 112 00:08:22,200 --> 00:08:25,890 not have written down in my notes and don't remember off the top of my head but I think I've got it 113 00:08:25,950 --> 00:08:27,120 on undo. 114 00:08:27,330 --> 00:08:29,720 No I don't whatever it's proxy. 115 00:08:29,720 --> 00:08:30,370 True. 116 00:08:30,450 --> 00:08:31,590 I'm pretty sure. 117 00:08:32,290 --> 00:08:33,380 So that's pretty much it. 118 00:08:33,630 --> 00:08:39,490 So we just say hey Google strategy if our request runs through any proxy that's totally fine. 119 00:08:39,660 --> 00:08:40,400 Just deal with it. 120 00:08:40,440 --> 00:08:46,530 You can just trust the proxy and calculate the callback you are l correctly. 121 00:08:47,220 --> 00:08:47,550 OK. 122 00:08:47,580 --> 00:08:48,720 So that's pretty much it. 123 00:08:49,080 --> 00:08:50,990 Let's now commit this change. 124 00:08:51,000 --> 00:08:55,040 We're going to redeploy it and then test our application again over on Roco. 125 00:08:55,410 --> 00:09:03,150 So I'm going to save this file I'm going to flip back over to my terminal or do a get status and verify 126 00:09:03,150 --> 00:09:05,860 that only my passport digests file is changed. 127 00:09:06,180 --> 00:09:15,960 I'm going to do a get at DOT and then I will commit that file and add tweak Google strategy settings 128 00:09:17,840 --> 00:09:23,660 and then I will push that to her again with good push Heroku master like so 129 00:09:26,500 --> 00:09:30,300 OK so that again is going to take just a minute to go through the deployment. 130 00:09:30,730 --> 00:09:33,450 I think that we should probably do you want to wait. 131 00:09:33,450 --> 00:09:35,430 Do you want to just I think it's going too fast. 132 00:09:35,440 --> 00:09:38,230 Fleshless let it do its thing and we can test it out right now. 133 00:09:38,530 --> 00:09:40,800 So I'm going to flip back over to my browser. 134 00:09:41,620 --> 00:09:48,940 I can open up a completely new tab and I'm going to visit my Heroku server again which is agile by you. 135 00:09:48,940 --> 00:09:54,110 Blah blah blah at her app dot com slash slash Google. 136 00:09:54,190 --> 00:09:59,380 And by the way just one quick thing because so many people make a very tight small typo here. 137 00:09:59,560 --> 00:10:02,890 Whenever we are accessing our deployed server we make. 138 00:10:02,890 --> 00:10:07,660 We are pointing at the domain Heroku app dot com not Heroku. 139 00:10:07,660 --> 00:10:11,250 Your server is at Heroku app dot com not Heroku. 140 00:10:11,950 --> 00:10:12,210 OK. 141 00:10:12,220 --> 00:10:14,170 So let's make sure the deployment is complete. 142 00:10:14,170 --> 00:10:15,640 It looks like it is. 143 00:10:15,640 --> 00:10:24,190 So now we will try the flow again and when we do so we successfully get redirected back to this still 144 00:10:24,190 --> 00:10:26,530 pending error message that we will later fix up. 145 00:10:26,650 --> 00:10:29,970 But this is what we saw previously on our development server before. 146 00:10:30,010 --> 00:10:35,890 So it looks like now everything is good to go and we can really test this out by going to Heroku app 147 00:10:35,890 --> 00:10:40,470 dot com slash API slash current user. 148 00:10:41,110 --> 00:10:44,380 And that will show me the current user die and logged in as. 149 00:10:44,410 --> 00:10:47,490 And of course I can always log out as well. 150 00:10:47,540 --> 00:10:47,960 OK. 151 00:10:48,040 --> 00:10:49,640 So that's pretty much it. 152 00:10:49,660 --> 00:10:54,090 I know this little proxy truth thing right here was kind of a pain. 153 00:10:54,100 --> 00:10:59,710 I apologize that I feel like I don't really want to go super far into detail around what's going on 154 00:10:59,710 --> 00:11:03,700 right here because honestly all this h stuff is a real rabbit hole. 155 00:11:03,760 --> 00:11:08,200 And as soon as we really dive into it it's endless and we can just talk for days. 156 00:11:08,200 --> 00:11:13,870 So at this point we can kind of just accept it and say all right the Google strategy says there's a 157 00:11:13,870 --> 00:11:14,680 proxy here. 158 00:11:14,680 --> 00:11:19,390 And so it's going to do something funky with the actual request or it's going to do something with its 159 00:11:19,390 --> 00:11:21,400 calculation of the domain. 160 00:11:21,400 --> 00:11:22,510 But we fixed it up. 161 00:11:22,510 --> 00:11:24,910 So I think that we are all ready to go. 162 00:11:24,910 --> 00:11:28,430 Let's now continue in the next section and continue working on our application.