At the moment the redirect code redirects HTTPS → HTTPS. I tried stopping the page with die($url) to see if the PROTOCOL is HTTP and it was correct. But for some reason when I try PHP header location it redirects back to HTTPS protocol rather than HTTP
So when I use following code in my Zend predispatch method
header('Location: http://www.example.com/blogs/');
it redirects to https://www.example.com/blogs/ (HTTPS PROTOCOL)
whereas when I try
header("Refresh:0; url=http://www.example.com/blogs/");
it works fine. Meaning it redirects to HTTP protocol.
Note: The reason I need to do this inside the controller is that redirects depend on a special flagpole. I cannot do it with Apache config.
I have finally solved this issue.
The problem was the redirection headers were being overridden by the loadbalancer. So there was some sort of policy set that if someone tries to redirect URL from one protocol to another it will not allow that causing the redirect loop that i was experiencing.
The solution in my particular case was another custom header that was needed to be sent which allowed scheme override in the loadbalancer.
Related
We have a client that hosts their IIS web server on AWS. When navigating to a particular PHP web application on this server, it works when there is a slash on the end, but not when it is absent.
this works:
https://example.com.au/application/
However, if one were to enter this into the address bar:
https://example.com.au/application
it redirects to the equivalent http address with a slash on the end:
http://example.com.au/application/
http is disabled via the firewall, so the result is an error.
Here is the request details in Chrome debugger
So my question is, what does my client need to check to ensure this redirect does not occur? or that instead of redirecting to HTTP, it redirects to HTTPS?
Additional info:
This same issue does not seem to occur with .NET web applications. Eg 'https://example.com.au/dotnetapp' will not redirect to 'http://example.com.au/dotnetapp/'.
There are no rules configured in "URL rewrite"
IIS logs show requests when the HTTPS url is triggered, but not the HTTP one.
Edit: This seems to be due to browser caching. After disabling browser caching, i can see the 301 entry in the log files.
'index.php' is set as a default document
One possible reason is that the PHP project doesn't know that the secure connection is active and so it's redirecting the page to the http version when adding the slash.
PHP application can detect the secure connection by the $_SERVER['SERVER_PORT'], $_SERVER['REQUEST_SCHEME']. But if the application is behind some reverse proxy (e.g. Varnish or Amazon’s Elastic Load Balancer), the connection to the PHP application is probably not secured. PHP should be informed about the original secure connection with X-Forwarded-* headers.
Please check if the PHP has these variables set:
$_SERVER['HTTP_X_FORWARDED_PROTO']: should be https,
$_SERVER['HTTP_X_FORWARDED_PORT']: should be 443.
Symfony framework
If the application is using the framework, e.g. Symfony, it should be configured to trust the IP of the reverse proxy and to trust also these headers:
# config/packages/framework.yaml
framework:
# ...
# the IP address (or range) of your proxy
trusted_proxies: '192.0.0.1,10.0.0.0/8'
# trust *all* "X-Forwarded-*" headers
trusted_headers: ['x-forwarded-for', 'x-forwarded-host', 'x-forwarded-proto', 'x-forwarded-port']
# or, if your proxy instead uses the "Forwarded" header
trusted_headers: ['forwarded']
See https://symfony.com/doc/current/deployment/proxies.html for more details and https://symfony.com/doc/current/deployment/proxies.html#but-what-if-the-ip-of-my-reverse-proxy-changes-constantly for more detaiils if the IP address of reverse proxy server changes.
Looks like you are setting location header in the 'index.php' file and so browser is redirecting to the http url.
If the index.php has code like below, replace the http to https and to the correct URL
header("location:http://example.com.au/application/");
Updated :
Also check your folder to see if any other files are redirecting.
Please make sure the index.php is listed as the first in the default document list and none of the other files contain redirect code.
You can search for "meta http-equiv="refresh" http tags in all the files in folder to see if they are redirecting.
I'm running a new site on Google App Engine with a custom domain and I want to require all traffic to come through via https.
I created a test script at http://rublonde.com/tmp:
<?
header("Strict-Transport-Security: max-age=180; includeSubdomains");
print $_SERVER['HTTP_X_FORWARDED_PROTO'];
(The content of the site doesn't really match the domain name, I'm just temporarily using this domain as a custom domain so I can get the HTTPS header thing working.)
In Google App Engine, the HTTP_X_FORWARDED_PROTO will be either http or https. On the first load of this page, I assumed it would get the the HSTS header and then on subsequent loads of the page, Chrome should automatically be requesting the page via https.
Am I misunderstanding how HSTS works? Am I doing something wrong?
Ah, I realized that HSTS headers are ignored when sent over an http connection (I think because they need to be associated with a valid certificate that comes with the https connection).
https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security#HSTS_mechanism_overview
A server implements an HSTS policy by supplying a header over an HTTPS
connection (HSTS headers over HTTP are ignored).
I need to perform a 302 redirect with PHP. I'm trying with header location.
It works well with HTTP. But, the redirect does not work with a custom protocol. For example:
header ('Location: magplus://myaccountview/login/');
How I can fix it?
For some browsers, you will not be able to redirect to a protocol other than HTTP or HTTPS. There is nothing you can do about that specifically.
You can try to change the location in the browser client-side with JavaScript, if that is a possibility for your application. That also won't always work however.
In my application I am setting the Location header to http://www.foo.com inside a route that responds to a POST request over HTTPS. I keep getting redirected to https://www.foo.com instead of the plain HTTP version. If you handle a POST over HTTPS will all redirects be forced over HTTPS as well?
This is on an Apache server running PHP 5.3.
The application I'm working on has rewrite rules in place to ensure that the user is always on https. In my fb application settings, I can define both the secure and nonsecure canvas page to use https (so no redirection will occur) but I cannot do the same on a tab page of the application. FB uses whatever protocol the user is running on as far as I can tell.
Because of this, when a user hits the application via http, mod_rewrite redirects the user to the https version. Redirects don't pass along form data. There was a thread I found that discussed using a proxy redirect but that doesn't seem to be working.
Is there some configuration setting I could use to turn my signed_request $_POST into a $_GET? Alternatively is there some api call I could make to get the signed_request? The facebook->getSignedRequest() simply looks in the $_REQUEST which due to the redirect contains no post data.
I'd do the redirect in PHP (using $_SERVER['HTTPS']) rather than via .htaccess, and do it after first saving the signed request data to the user's session.
I have the same problem here. When I visit the tab using HTTPS I get the signed_request just fine because there's not redirect happening.
I run another Facebook app on the same server and it uses an htaccess file to make sure the files are served over HTTPS. So, What I ended up doing was making sure that the sub folder I'm working in is excluded from the rewrite. Like so:
RewriteCond %{THE_REQUEST} !/my-app-folder
Then, in my PHP I do a check to see if the referer is HTTP. If it is not, I change the header to an HTTPS version of my app. Like so:
$referer = $_SERVER['HTTP_REFERER'];
if (substr($referer,0,5) != 'https') {
header("Location: https://www.facebook.com/myapp?sk=app_xxxxxxxxxxxxxx");
}
This is probably not fool proof, but once I click that like button, I definitely get the results I need. I tested this in the dreaded IE as well and it appears to be working there too.
Some browsers do redirect your request to https automatically if you have been on this particular site on https so if you are in http mode on facebook there is situation:
facebook requests http version of your app, browser redirect this request of facebook to https and POST data and thus signer_request are gone in this process...
i see this problem in chrome 23, if you delete browsing data (particulary "Deauthorize content licenses") app should run back on http