Which way of redirecting from one page to other is more reliable? I need to to have a link that bring the user to blank page where some php code is executed first(in the background) and then it redirects to the target page. I would like to make this seamless, so the user is not aware that he was redirected. I used javascript for that and it worked fine, but with Javascript disabled it simply won't work. Will php redirection work in this case? Can the header() function be used after some other php code has been executed? All advice appreciated.
Redirecting from PHP with header('Location: '.$URL); die; is the most dependable redirect you can do (since it works at the HTTP level).
The only catch is that you cannot redirect this way if you have produced any output already. This is something that you can avoid by simply thinking through your code flow and designing appropriately, but if push comes to shove you can shoehorn it into an existing code base by utilizing PHP's output buffering capabilities (basic example here).
Yes, header can be called after you run php code, just be sure you don't output any text. Then send a location header.
PHP redirection will work if you didnt send any output before the header. But yes, its easy to notice that you are redirected.
yes you can execute code with PHP before a redirect. Just be certain to use the right HTTP status code for the job. (I assume the default 302 will be appropriate, but you never know.)
This method will alert the client's machine of the redirect, but tends to be seamless enough that the average user wont notice.
Why not use AJAX to call a script that processes data, and then when that AJAX is complete you can redirect to the external page?
If all your first script does is calculate data and redirect, without returning any real content, then there's not a lot of point in forcing the page to be synchronously loaded and displayed with a normal HTTP request. I assume you are allowed to use JavaScript since that's in your question.
Related
I've got some PHP which handles a GET request via a query string. Once processing on that query string is done, it generates a page with the results.
So far so good. But the url in the browser keeps the query string, so e.g. if you hit reload, it again tries to process the GET.
So I'd like to generate the page, but return without the query string. I've tried setting the header() to the URL-minus-query, but that redirects (i.e. reloads) the page, rather than returning directly.
I'd think this is a common and easy task, but I can't find a solution...!
In case anyone runs across this post...
For the general case, given the difficulty of changing the url server-side, it's easiest to go through the effort to make it a POST, or use AJAX.
update: But in my case, it's a page where the user can change account information, which then needed to be reflected on that page. The answer in this case is simple: do the database updates first, then just redirect to the same page: parse_url($_SERVER['REQUEST_URI'],PHP_URL_PATH)
Regular PHP processing handles the rest.
The core problem is that you absolutely MUST NOT use GET for processing anything. GET should be safe and refreshing should have no side-effect. Generally the way people solve this is by:
Doing some processing with a POST request
Redirect to a 'results' page.
The most correct redirect status code for this is 303 See Other, but must frameworks will use 302 Found.
I'm trying to figure out if I can do the following:
User submits form to script via jquery post
Depending on what was processed, script may or may not return errors
If the script did not process any errors (i.e. SUCCESS), I want to redirect to a SUCCESS page
I know it's possible to redirect the browser via javascript, but I'm worried if some users have javascript disabled the entire flow might get messed up.
Thanks in advance.
As you want to evaluate the form (currently) with jQuery, you can safely assume that, when the form is evaluated, JavaScript is available.
For those without JavaScript, you should add some server side routine, that does the job. And then you can use a redirect via HTTP header, or a <meta> redirect.
To keep both ways working, hard code the server side routine into the code, and replace it via jQuery when the page is loaded. JavaScript users will execute the jQuery replacement and get the jQuery evaluation; other's will just stay with the normal version.
I am working on a PHP application and missing some of the functionality that Rails has. I currently have an AJAX form that when submitted accesses my_page_save_ajax.php. After I process the form and save it, I would like to redirect the AJAX call to either my_page_show_ajax.php if successful or back to my_page_edit_ajax.php if an error occurred.
I have thought about using an include my_page_..._ajax.php, but I have always had problems with the file paths and PHP not knowing what to render. Not to mention, both of those files include utilities.php and I'm afraid there might be conflicts. I guess I could use include_once but it seems like there might be a more elegant solution.
How can I process the form and return the output of another PHP page?
Thanks very much!
If you redirect the AJAX response, it won't actually redirect the user's browser anywhere. It will simply affect what data comes back through the AJAX call. This may be a good instance to simply not use AJAX, since it sounds like the user may go on only one of two paths.
If you still want to redirect the user, you could send back a javascript snippet which redirects the user via setting window.location
How to make sure a human doesn't view the results from a PHP script URL?
Recently when viewing the source of a site that was making an AJAX call, I tried to follow the link in the browser
www.site.com/script.php?query=value
Instead of getting the result I expected to see, I saw a message stating only scripts should view that page.
How do you restrict a script to only allowing a script to access it?
UPDATE:
here is the page DEMO page
Short answer: you can't.
Long answer: You can make it harder to do it by requiring special header values in the HTTP request (setting Accept to application/json is a common one). On the server side just check to make sure that header is set to the value you expect. This will make it so that regular users will get the message you mention and your scripts will work just fine. Of course advanced users will be able to easily work around that sort of limitation so don't rely on it for security.
with php you can check for and only display results if the page is called via ajax
function isAjax() {
return (isset($_SERVER['HTTP_X_REQUESTED_WITH']) && ($_SERVER['HTTP_X_REQUESTED_WITH'] == 'XMLHttpRequest'));
}
if(isAjax()) {
// display content
} else {
// not ajax, dont show
echo 'Invalid Request';
}
You can't. A human being can always spoof the request. You can send your request with a post variable, to make sure a human doesn't end up on the page by accident.
One possible solution is to check the HTTP Request for it's origin.
Another solution is to send a "password" with every request. Take a look into this tutorial how to do this.
But it's never 100% secure, it only makes it harder for possible intruders.
As Tim stated, this script is almost certainly looking for this request header, which is being sent with each request to rpc.php (found via the net panel in firebug, naturally):
X-Requested-With : XMLHttpRequest
As to cross-browser compatibility, the setRequestHeader method appears to be available with both the activex and xmlhttprequest connections so this should work in all major modern browsers.
If you are calling the script by AJAX, then it MUST be accessible for you because an AJAX call is similar to your browser actually asking for the page, thus it is not only script accessible but accessible to anyone.
If it was actually called by PHP or by some other means, you could "maybe" use Apache rules or PHP scripting to diminish the accessibility.
You could set a secret value into the php session with the 'view' script and check for it with the ajax scripts.
Request 'index.php' with the
browser.
PHP builds the page, saves a key into
the session, sends the content back
to the browser.
The browser gets the page content and
makes some ajax request to your site.
Those ajax scripts also have access
to the same session your main page
did, which allows you to check for a
key.
This insures only authenticated browsers are allow to make the ajax requests.
Don't count on the ajax request being able to write to the session though. With many requests being satisfied at the same time, the last one in will be the last one written back to your session storage.
http://us.php.net/manual/en/book.session.php
A lot of open source applications use a variation of this on top of every php file:
if (!defined('SOMETHING')) {
die('only scripts have direct access');
}
Then in index.php they define SOMETHING:
define("SOMETHING", "access granted.");
edit: I'm not saying this is a good approach btw
edit2: Seems I missed the part about it being an ajax request. I agree in this case this isn't a solution.
How do I prevent my users from accessing directly pages meant for ajax calls only?
Passing a key during ajax call seems like a solution, whereas access without the key will not be processed. But it is also easy to fabricate the key, no? Curse of View Source...
p/s: Using Apache as webserver.
EDIT: To answer why, I have jQuery ui-tabs in my index.php, and inside those tabs are forms with scripts, which won't work if they're accessed directly. Why a user would want to do that, I don't know, I just figure I'd be more user friendly by preventing direct access to forms without validation scripts.
There is no way of guaranteeing that they're accessing it through AJAX. Both direct access and AJAX access come from the client, so it can easily be faked.
Why do you want to do this anyways?
If it's because the PHP code isn't very secure, make the PHP code more secure. (For example, if your AJAX passes the user id to the PHP file, write code in the PHP file to make sure that is the correct user id.)
As others have said, Ajax request can be emulated be creating the proper headers.
If you want to have a basic check to see if the request is an Ajax request you can use:
if($_SERVER['HTTP_X_REQUESTED_WITH'] == 'XMLHttpRequest') {
//Request identified as ajax request
}
However you should never base your security on this check. It will eliminate direct accesses to the page if that is what you need.
It sounds like you might be going about things the wrong way. An AJAX call is just like a standard page request, only by convention the response is not intended for display to the user.
It is, however, still a client request, and so you must be happy for the client to be able to see the response. Obfuscating access using a "key" in this way only serves to complicate things.
I'd actually say the "curse" of view source is a small weapon in the fight against security through obscurity.
So what's your reason for wanting to do this?
If the browser will call your page, either by normal request or ajax, then someone can call it manually. There really isn't a well defined difference between normal and ajax requests as far as the server-client communication goes.
Common case is to pass a header to the server that says "this request was done by ajax". If you're using Prototype, it automatically sets the http header "X-Requested-With" to "XMLHttpRequest" and also some other headers including the prototype version. (See more at http://www.prototypejs.org/api/ajax/options at "requestHeaders" )
Add: In case you're using another AJAX library you can probably add your own header. This is useful for knowing what type of request it was on the server side, and for avoiding simple cases when an ajax page would be requested in the browser. It does not protect your request from everyone because you can't.
COOKIES are not secure... try the $_SESSION. That's pretty much one of the few things that you can actually rely on cross-page that can't be spoofed. Because, of course, it essentially never leaves your control.
thanks, albeit I use
define('IS_AJAX', isset($_SERVER['HTTP_X_REQUESTED_WITH']) && strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) == 'xmlhttprequest');
if(IS_AJAX) {
//Request identified as ajax request
}
cheers!
Not sure about this, but possibly check for a referrer header? i think if someone manually typed in your url, it wouldn't have a referrer header, while AJAX calls do (at least in the quickly test I just did on my system).
It's a bad way of checking though. Referrer can be blank for a lot of reasons. Are you trying to stop people from using your web service as a public service or something?
After reading your edit comments, if the forms will be loaded via ajax calls, than you could check window.location to see if the url is your ajax form's url. if it is, go to the right page via document.location
This definitely isn't useful for securing something.. but I think this could be of use if you wanted to have say a php page that generated a whole page if the page was not requested by ajax but only generate the part that you needed returned when ajax was used.. This would allow you to make your site non ajax friendly so if say they click on a link and it's supposed to load a box of comments but they don't have ajax it still sends them to the page that is then generated as a whole page displaying the comments.
Pass your direct requests through index.php and your ajax requests through ajax.php and then dont let the user browse to any other source file directly - make sure that index.php and ajax.php have the appropriate logic to include the code they need.
In the javascript file that calls the script:
var url = "http://website.com/ajax.php?say=hello+world";
xmlHttp.open("GET", url, true);
xmlHttp.setRequestHeader('X-Requested-With', 'XMLHttpRequest');
then in the php file ajax.php:
if($_SERVER['HTTP_X_REQUESTED_WITH'] != "XMLHttpRequest") {
header("Location: http://website.com");
die();
}
Geeks can still call the ajax.php script by forging the header but the rest of my script requires sessions so execution ends when no valid session is detected. I needed this to work in order to redirect people with expired hybridauth sessions to the main site in order to login again because they ended up being redirected to the ajax script.