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
Related
I have a codeigniter project. Recently I deployed it with SSL. And I forced my site to use Https from http by modifying in .htaccess and changed baseurl too. The problem is I have a registration and login form . When changed from http to Https the form doesn't submits and the entry in dB is also not made...,any thing till I wanna change?
Make sure the value of base_url in config.php uses https, i.e.
$config['base_url'] = "https://example.com/";
Usually it because the html try to load non https sources.
You can see the blocked requests on chrome console.
Make sure all your sources (css, js, fonts) are loading with relative urls, anr\or change hard-coded and external links to https
Contact Form 7 works only if I add https:// before my domain. If i access it with www.example.com withot 'https://' before, after I submit the form I get only spinning wheel and not sending the mail.
In inspector it says: "'Access-Control-Allow-Origin'".
I just transfered wordpress website from local to the server.
Also, my base is all set to https://www.example.com. I tried changing everything in DB to www.example.com and it still doesn't work.
Thanks
Changed everything https://www.example.com to http://www.example.com and boom. Now it works on both sides.
Thanks
When you try to submit from the http side then you're probably finding that the submit goes to a http form handler. From there it redirects to the https version of the form handler, however the redirect doesn't pass on the POST variables so the handler never receives any data and doesn't send the email. Set your entire site to HTTPS and use HSTS as well.
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.
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.
Whenever I get a 404 our logout script is being called mysteriously. What should be happening is our custom ErrorDocument defined in the root .htaccess file should be redirecting to a static HTML page, without any external logout actions being initiated.
I'm using Zend Studio's debugger and at first everything goes as expected -- it serves up the 404. But immediately afterward a separate request is picked up by the debugger which calls the logout page.
I can't find out what is initiating this second request. I stepped through the entire request that serves up the 404 and there were no headers or redirects that would cause this to happen. It seems like something external may be going on here, but I can't locate it.
I've examined the php.ini and httpd.conf files for anything suspicious being initiated in the event of a 404 but with no luck. Any idea how I might debug the source of this second request for the logout page?
try to build some kind of tracking in the logout script. Try to track who calls is - if the request comes from the same client IP as 404 page request, or maybe there is a code somewhere in your app (e.g. file_get_contents()), where request is being generated from server itself (then 404 page request would have different IP compared to logout request, which comes after it)