First of all, this is my first post in Stack Overflow and I'm trying to learn PHP/MySql for a personal project that I'm working on. I think I will be spending alot of time on here to ask heaps of questions, so forgive me if I ask too many questions that you may find trivial.
On with the question.
I'm using a combination of ajax and PHP to process server side scripts. What I want to do is have a PHP module that will accept input, process something, and provide output. Much like a function.
What I'm trying to wrap my head around is how can I make PHP like a black box process module, like a function, rather than a page.
As an example, I have a login.html page which uses AJAX to send request to a login.php page. The login.php accepts the input, process the input, and output a json object which tells the calling page if it is successful, and if not will list the errors that it encountered along the way.
Here lies the issue. I don't want user to be able to go to login.php directly. In fact, I don't even want login.php to be visible to the public. The login.php is only a process, so if you go to it, it will be blank. This doesn't seem like a good practice to let users see a blank page.
I thought about putting the login.php outside the public folder, but this would mean that ajax won't be able to make a request to it either.
To get around this I have the login.html sit within the login.php. It will make a request to itself, then based on the type of request, the php will perform different things. This will resolve the "blank page" issue. But I can't help wonder if there is a way to make a standalone PHP module without having to make it work like a page also.
Any thoughts into this will be much appreciated. Thanks.
If an AJAX can request the page, then any user will be able to navigate to the page with their browser. You really shouldn't be concerned with this, because unless they snoop around they won't happen upon the PHP page. If you want a little bit of verification that the request was made by AJAX you can look for the X-Requested-With header, but this doesn't always work because every browser doesn't send this:
if(isset($_SERVER['HTTP_X_REQUESTED_WITH']) && $_SERVER['HTTP_X_REQUESTED_WITH'] == 'XMLHttpRequest') {
// Ajax Request
} else {
// Not AJAX, redirect to login page
header('Location: login.html');
exit();
}
To make this work reliably on every browser, you'll need to set this header on the clientside:
xhr.setRequestHeader("X-Requested-With", "XMLHttpRequest");
However this is still not fullproof because anyone can send a header with a program like Tamperdata, but this should be good enough to prevent the lazy snoop. Again though, allowing users to see this page (if they snoop) won't be a huge problem. It's not going to create a security vulnerability and on the off chance that a user stumbles upon the login.php page, they'll be redirected back to login.html.
Anything you send an AJAX request to can also be navigated to directly, by the nature of AJAX. All you can do is not provide the user with any indication that that page exists.
You do have the option of having one PHP file call another, via include. That way, you can have the request to login.php change behavior based on the request, but have the login handling actually processed by a file that isn't publicly accessible:
if($_POST) {include '../login-handler.php'; die();}
Related
For some reason I need to process PHP behind the scenes but not using AJAX (I know that might sound silly to you). I need this since I am getting the content dynamically through another page loading.
By using PHP's curl functions I can get the login page of a website inside my 1.php file. But then I use javascript to set form values and hit login and it takes me to the site url (not already localhost/1.php). So the question is: I need to somehow store the content of the page that I am redirected and retrieve it .
The impression i got was that, you have a resource intensive process, which would perform some action in background , while user still interacts whit the page.
I actually would make more sense to do this with some sort of service ( as shell script or standalone application ), but it is possible to do with php: you would need to fork [1] [2] the process. Just don' forget to check, if one such process is already running on the system.
It actually works pretty well in combination with XHR (also know as AJAX by marketing department), because you can kick off the process with a request, and then repeatedly check the status .. and then collect the data, when status is "done".
Since we're all taking stabs in the dark, here's what I think you're trying to do (let me know if I'm way off):
You have a site (let's call it userfriendly.org) and you are trying to add an interface of some kind to another site (we'lll call this site mean-corp.com). Essentially, when you load the page, you use curl to fetch some of the data from mean-corp.com so that your users can login and get some info but without having to deal with their site (maybe it's ugly, maybe it just fits really well into your site, whatever).
You are able to get to the site okay to get whatever initial data you need, but when you try to pass in the user login and password to actually get their info, it's redirecting back to the login URL for the site.
Long story short, you are trying to make a front-to-back web service for another site, but you're running into hiccups with redirects and whatnot?
Am I totally off? If not, I've made similar attempts in the past for my own nobel reasons,and I could pass along some tips as I'm sure others can.
But if I'm totally off, sorry for the distraction.
If a user tries to log in and the login fails the page should display an error message to the user. There are two main ways I see to do this: use a form action on the HTML page and in the php script if the login information is incorrect redirect with header to the login page with a $_GET value like loginfailed. The login page would check for this value and if it exists it would display the error.
The second way I see to do this is not use a form at all and instead use JQuery to capture the submit button press and use AJAX to determine if an error occurs. The php file would echo back a status and the javascript file would interpret it and if it was loginfailed, it would use JQuery to append the error message on to the page.
Now I will go over what I feel the pros and cons of each method are.
Method 1 Pros:
Very simplistic with no need for JQuery, Javascript, and AJAX.
The error status is displayed within the URL as well.
Method 1 Cons:
Since there is a header call, a redirect is necessary. Also, the login page must be reloaded. It is a small page but it is a reload nonetheless.
The status message is displayed in the URL. This means that users can type in status messages in to the URL and receive error messages on the page for errors that did not actually occur. Is this a problem? Maybe. Maybe not.
Method 2 Pros:
Since it is using AJAX, there is no need to load another URL and thus, no extra page is loaded.
This method uses JQuery to update the page with the error message so no redirect is necessary.
The error status is not displayed in the URL.
Method 2 Cons:
Much more complex than the first solution.
An external javascript file is needed and must be loaded every time the login page is accessed regardless of whether or not it is used.
The default behavior of the submit button is overridden and annulled. Its only behavior comes from its interaction with the javascript file.
What would SO do? I would like to stay away from answers such as "it depends on how much traffic your site would have" if that would be at all possible.
Always use the simplest solution possible until/unless there's a very good reason to do otherwise. It's better to finish something that's maybe (and maybe not) less than ideal than to deliver something gold-plated eventually, maybe.
Also, I generally prefer to follow a progressive enhancement strategy, such that everything works without Javascript, and then add Javascript to make it work in an improved manner. This has the added benefit of being functional, even when/where Javascript is disabled.
I think you fail to grasp the matter.
Login is not something self-sufficient. It is used to change state of the site. But with no reload it will not be changed. So, page reload is required anyway. or user will have to do it manually to get access to the authorized section.
Is login the only site feature that uses JQuery/AJAX? If not - why you're worrying about loading this library once, when most likely it will be loaded at every page?
There are still clients with JS disabled, for various reasons. A good web application will always let these clients in, even at cost of less functionality.
The latter is the main question, most important one. Why to choose between two? Why not to use both? - one for compatibility and another for usability?
So, I'd suggest to create basic functionality using GET to pass come codes, not messages.
And optionally improve it with some AJAX bells and whistles but with JS-based reload on succesful login anyway
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.