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)
Related
I need to access http://server.com/folder and get a default index.php file with NO REDIRECT , which means I need Apache to deliver http://server.com/folder/index.php when http://server.com/folder is called with no redirect. How can this be done? I see many solutions but some do not seem to work or perhaps are incomplete while other cause a redirect. The client I want to use is Mopira for Scanning and does not respond to the redirect as I suspect others will not as well.
This is Apache2 running on a local Ubuntu server so i is not a server exposed to the Internet
Alternately if I can force http://server.com/filename to load http://server.com/filename.php with no redirects this would also work but redirects do not work!
here is what I want
if someone entered a link that does not exist ,then it should throw 404 Error page of webhost,But currently it is returning 200.
www.example.com/wrong_page.php --> this should throw an error 404 but
is is throwing 200 right now.I SEE SAME PAGE AS
www.example.com/index.php
What might have gone wrong ? is there any configuration that is needed to be done in the htaccess.php ? please help
Most likely you have some already existing rewriting rule in effect, that is all.
Something that redirects all requests to /index.php which actually is a quite common thing in web applications. Such index script acts as a router, processing all requests. This serves as a central entry point and simplifies to define the structure of the implemented engine.
So you should look for already existing internal rewriting rules inside the http servers host configuration or in some dynamic configuration file (".htaccess").
let php send the header 404: (in wrong.php)
<?php
header("HTTP/1.0 404 Not Found");
?>
re-reading your question: is wrong_page.php your error page, or just your example of the non exsiting page?
If so: do you have a custom error page on you site? Then place this headerline in that file
edit: (question was changed)
So the index.php is still loading.
Is no 404 template for seen?
maybe there is some page that actually exists at that location. Otherwise that would never be the case
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.
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
I'm working with an intranet system that, on each page, checks the user's cookie, verifies that they can see the current page based on database permissions, and records a page hit that includes their id and the page URL.
I just noticed that in the pagehits table, I see an entry for 404.php (my custom 404 page specified in the Apache config) one second after each legitimate page hit.
Is this probably my fault, or does it have something to do with how Apache decides to load the 404 page?
I'm using Apache 2.2.14 (Win32) and PHP 5.3.2.
My guess would be that you have no favicon.ico defined for your site.
That means that every time a user requests a page, the browser is also requesting favicon.ico which results in a 404 being returned.
You probably have a request for a file which doesn't exist. Maybe your favicon. The Apache error or access logs will reveal what the 404 was for.
Try reading your logs and see which url trigger the 404 response code. Also you can install some log analyzer like awstats