Here is the situation in the smallest explanation I can give.
From php, I do a redirect with the following function
function redirect($loc)
{
session_write_close();
header("Location: $loc");
exit();
}
For example, redirect('http://www.google.com/');
The problem is that when I attempt to do redirect('https://local.application.com')
the browser gets a header that says Location: https://local-apps.application.com
. https://local-apps.application.com
is the uri that the original request comes through.
I've used xdebug to step through the php code right up to header('Location: $loc');
call and I can verify 100% that $loc == 'https://local.application.com'
because xdebug tells me so. However, for SOME reason, the browser gets Location: https://local-apps.application.com
. This causes an infinite loop as https://local-apps.application.com
once again redirects to https://local.application.com
.
What is maybe going on?!
The extremely weird part is that putting the SAME EXACT code in our qa environment yields the expected behavior and NO INIFINITE loop is caused. In qa the urls are qa-apps.application.com and qa.application.com.
I don't know if my local Apache is doing this. I doubt it's php's fault because xdebug shows me for certain that the $loc variable is set to the right uri and I'm doing an exit
right after.
I've also tried using Charles web proxy to act as a man in the middle to look at traffic but it also shows Location: https://local-apps.application.com
instead of the expected Location: https://local.application.com
.
Is there an Apache setting that would alter outgoing headers? What should I do?
EDIT 1
I altered my Apache access log to print out the Location header in the response and it is the correct value. So apache isn't doing anything weird here.
EDIT 2
I removed all entries from my /etc/hosts file. I then installed dnsmasq and set it up as the primary DNS server for my computer. I tested this by doing dig @127.0.0.1 local.application.com
and then dig @127.0.0.1 www.google.com
to make sure I had set it up correctly.
I added address=/local.application.com/127.0.0.1
and address=/local-apps.application.com/127.0.0.1
to the dnsmasq config and restarted dnsmasq. I even restarted my computer after setting it up as a daemon that starts on reboot.
I get the same weird behavior on my local machine. My webbrowser goes into an infinite loop.
More info if you are curious
I'm putting together an oauth2 implementation in my workplace.
The authorize point exists on my local machine at local-apps.application.com/authorize (local-apps) because that's where mobile apps will access it. In production it would be apps.application.com/authorize. (Sorry, I can't control the subdomains being used).
Depending on the client_id in the initial oauth2 auhorize request I will first redirect to a client appropriate domain. From local-apps.application.com/authorize
I'll go to local.client-1.com/authorize
and then from there I would redirect to local.client-1.com/login
if the oauth2 credentials are validated successfully.. Why the extra redirect? 1. A limitation in the way our templating system works and the fact that it depends on the domain to load the proper html. 2. The sessions for php don't transfer across domains so I have to start the php session on the right domain. I can't change it. I just have to deal with it. Please don't make suggestions related to this url scheme thingy. I just want to know why php redirects to one url and the browser get a different url in the header.