In the last section we finished deploying our application to Heroku.
But when we tried to test out the overflow we got another nasty redirect you or I mismatched mess message.
So remember we've seen this message in the past.
It means that wherever we are trying to redirect our user to after they go into our waterflow is not
white listed as a valid callback address.
Now this is kind of confusing because we literally just configure that address two seconds ago on the
Google API manager over here.
And so hey here's the address right here.
Looks an awful lot like the one we are trying to redirect the user to right here.
But if you look very closely you'll notice that the redirect you or I that Google thinks that we are
trying to send the user to is P adj I'll buy you at her good outcome blah blah blah but over in our
authorized redirect you or I we specify that address as age TTP s.
So clearly at some point in time something here is breaking and reverting back to age TTP rather than
age to us now for everything that we ever do inside of our application that is tied to authentication.
We always want to use HTP us wherever possible because we are in theory handling some sensitive or authorized
data that we don't want to accidentally make available or leak out to other people who are inspecting
our traffic.
So we want to somehow figure out what's going on here and figure out how to fix it.
So the cause of this problem right here.
We're going to kind of jump to the you know jump to the conclusion here because it's kind of hard to
lead him too nicely.
Essentially this HTP is being generated by a combination of two different factors.
So I can assure you the two factors I'm going to tell you about two different solutions that we can
possible use.
And then we'll go ahead and fix this thing up.
OK.
So let's get to it.
So factor number one that is causing that link to revert back to age TTP and not use the age teach us
that we would hope that it would use is located inside of our services passports.
File.
So inside of this file right here I'm going to scroll down and find my Google strategy.
So here's the Google strategy right here inside of the initial configuration object that we passed in.
We specified a callback u r l that uses a relative path a relative path.
Now the fact that it's relative right here is issue number one that causes the HGT P.S. to drop out
of the address right here or at least make google think that we are trying to send a user back to an
HTP address when we only provide in a relative path right here.
It allows us greater flexibility as we develop and deploy our application.
So as you and I work on our application on both the development environment and then later push it up
to production we can use this callback you RL that uses a relative path right here to not really have
to worry about the different actual callback you are all domains that we want to send our users to think
about it when we are running our code in development.
We want the real true callback.
You are able to be localhost Kolin 5000.
Right.
But when we are in development we want it to be whatever my address is by use something at Heroku app
dot com slash whatever.
So by using the relative callback you are l it means we don't have to really worry about what domain
we are going to try to send the user back to IN THE END.
It is the Google strategy itself that is going to do a little bit of magic to figure out what domain
to put on here.
So it is the Google strategy right now that is deciding what domain to append to the request.
So clearly the real culprit here the real place where everything is going wrong is actually inside of
the Google strategy inside of our developer environment.
It is depending on the correct domain to this callback you IRL but in production it is doing the wrong
thing.
So again that is factor number one.
That's number one thing that is causing things to go wrong here.
Now by default the Google strategy actually does things more or less correctly.
It kind of does things the right way.
It is well written so to speak.
The reason that is doing things incorrectly is because of the second factor.
The other thing that is kind of going wrong with the way our application is deployed.
So this other factor I can't tell you right now this is a very extremely deeply complex topic and I
was going to give you a little bit of a taste on exactly why the Google strategy is doing things incorrectly
set up a diagram.
So this is a diagram of what happens when ever our browser makes a request to our server running on
Hoku servers.
So this would be like our server at Heroku.
So when you and I deploy our application over to Trochu it is running internally on Heroku network which
to be fair is actually hosted on AWOS but that's not really relevant right now.
When we deploy our server it is running on some like very far away hit in virtual machine that is running
along with many other servers at the same time as well.
In order to make sure that traffic from our browser is routed to the correct server Heroku uses a proxy
or a load balancer really its a proxy to make sure that traffic from our browser is routed to the correct
server on its internal network.
Now the issue here.
The reason that like the whole second problem here the reason the Google strategy is calculated that
Domingue incorrectly is that by default the the strategy assumes that if our request from the browser
ever went through any type of proxy then the request should no longer be age to us because it inherently
does not want to trust requests that come through a proxy.
Now in our case we are completely fine trusting the Heroku proxy here like our application is being
hosted on Roku.
Yes we really are OK with the security provided by Heroku and it is completely okay to trust in the
Heroku proxy.
So essentially what we have to do as one possible solution is add one configuration option to our Google
strategy to tell it to trust any proxies that the browser encounters between our server and the original
request.
Again we're not going super deep into like the real technical details here.
I really just want to give you a taste of kind of what's going on rather than saying oh yeah I was going
to use a little setting and say like OK it's fixed.
So that is one possible solution we can add one more setting to the Google strategy.
The other possible solution is to just spell out the entire callback you are l right here.
So rather than passing in just the relative path we could provide the fully qualified path like so.
So the entire thing for development would be like that.
And then for production we could spell out HTP Yes.
And then you know by you or whatever got her through app dot com so we can go either direction one way
or the other.
Now for me I think that life is a little bit easier to just use the relative path right here and not
have to do some runtime decision on whether or not we want to use the local host domain or this one
right here.
So for me I'm going to choose to go with this solution where we pass an additional option to the Google
strategy but we also could have very easily done something where we figure out the domain on the fly
and just in case you're curious we would have just very easily done it probably by adding another little
key to one of our production or development key files.
So we could have easily said inside of one of these like oh yeah Google redirects you or I and then
passed in say a CPS by you Heroku at dot com and all that kind of stuff.
So just as an example like hey it's really pretty easy either way.
I'm just going to go with one direction that is.
I feel like slightly easier.
OK so now I clean this thing back up make sure it only says off.
Slash Google slash callback and then the second option that we want to put in here that I kind of do
not have written down in my notes and don't remember off the top of my head but I think I've got it
on undo.
No I don't whatever it's proxy.
True.
I'm pretty sure.
So that's pretty much it.
So we just say hey Google strategy if our request runs through any proxy that's totally fine.
Just deal with it.
You can just trust the proxy and calculate the callback you are l correctly.
OK.
So that's pretty much it.
Let's now commit this change.
We're going to redeploy it and then test our application again over on Roco.
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
that only my passport digests file is changed.
I'm going to do a get at DOT and then I will commit that file and add tweak Google strategy settings
and then I will push that to her again with good push Heroku master like so
OK so that again is going to take just a minute to go through the deployment.
I think that we should probably do you want to wait.
Do you want to just I think it's going too fast.
Fleshless let it do its thing and we can test it out right now.
So I'm going to flip back over to my browser.
I can open up a completely new tab and I'm going to visit my Heroku server again which is agile by you.
Blah blah blah at her app dot com slash slash Google.
And by the way just one quick thing because so many people make a very tight small typo here.
Whenever we are accessing our deployed server we make.
We are pointing at the domain Heroku app dot com not Heroku.
Your server is at Heroku app dot com not Heroku.
OK.
So let's make sure the deployment is complete.
It looks like it is.
So now we will try the flow again and when we do so we successfully get redirected back to this still
pending error message that we will later fix up.
But this is what we saw previously on our development server before.
So it looks like now everything is good to go and we can really test this out by going to Heroku app
dot com slash API slash current user.
And that will show me the current user die and logged in as.
And of course I can always log out as well.
OK.
So that's pretty much it.
I know this little proxy truth thing right here was kind of a pain.
I apologize that I feel like I don't really want to go super far into detail around what's going on
right here because honestly all this h stuff is a real rabbit hole.
And as soon as we really dive into it it's endless and we can just talk for days.
So at this point we can kind of just accept it and say all right the Google strategy says there's a
proxy here.
And so it's going to do something funky with the actual request or it's going to do something with its
calculation of the domain.
But we fixed it up.
So I think that we are all ready to go.
Let's now continue in the next section and continue working on our application.