| Re: php includes and ajax [message #173105 is a reply to message #173087] |
Tue, 22 March 2011 00:06   |
HaleLOIS
Messages: 10
Registered: December 2010
Karma:
|
Junior Member |
|
|
I have not been able to post back to this forum for the last few hours, the server hasn't been responding... I've lost my post a couple times I hope it gets through this time.
> Which can easily be faked on the client. There is absolutely NOTHING to
prevent me from creating my own page with the buttons, for instance, and
submitting it to your server.
Perhaps I have not explained myself well enough. I AM doing server side verification. So I don't need counseling on security. The administrative divs ARE created by php user verification in the first place, the buttons on the jquery-ui dialog interface are created afterwards using an ajax style verification. You can fake those buttons all you want tricking the ajax call, but those buttons won't do anything if you're not a real administrator because the administrative div that they pull up (or unhide) won't exist on the page unless you are an administrator. I hope I have explained that better.
> The first thing to do is to FORGET ABOUT AJAX!
Well, I would say that this affirmation is not very informed or open-minded. I don't if you have ever used ajax or if you know what it is useful for. AJAX does not substitute server-side coding. All AJAX does is create an asynchronous channel of communication between the client and the server in such a way as to not have to refresh the entire page.
Maybe we need an overview of what actually happens when opening a website. All interaction on a website is "handshakes", requests and responses, between CLIENT and SERVER, not between javascript and php. Javascript works on the client side, php works on the server side, but the communication is between the client and the server. They can use other languages to formulate the request and the response, in this case we're having a discussion about the php language for formulating the response and javascript for intervening on the formulation of the request.
What happens in the "traditional" model of client-server communication? The request is formulated by the client, perhaps with the help of a client-side language such as javascript, and is submitted to the server via the url querystring which makes a GET request or through the submission of a form which can make either a querystring GET request or a "background" POST request. In either case the only way to submit the request is to refresh the whole page and wait for the response from the server, and then display the page again according to the response received from the server (and this response in the meantime has been processed by a server-side programming language such as php).
So where does AJAX come into the picture? You say:
> php knows nothing about AJAX
I'm not sure you have understood AJAX. PHP pre-processes web pages, and processes GET and POST requests and formulates responses. All ajax does is help FORMULATE or initiate the request to be sent to the server (and to be processed by php) without having to refresh the whole page. PHP knows just as much about ajax as it does about any kind of requests received from the client.
I think that there is a big advantage in not having to refresh a page continuously for every request sent to the server, sometimes you only have to update a fragment of a page and not a whole page. So it makes more sense, and it makes for more pleasant navigation and use of a webpage, if you do more background processing and only update those parts of the page that need to be updated to display the server's answer to a request that was sent.
AJAX is no less secure than any other client initiated request. You can just as well fake a form submit as you can an ajax request, so that's not the problem. As long as you have the correct server-side safety processing it doesn't make a difference whether your request is through a page refresh or through an asynchronous - background process.
Getting back to the point: my question is about how server-side php includes are to be handled semantically in a php file (to which an ajax request will be sent). The php include is a PHP INCLUDE, not a javascript include! If Jerry Stuckle reads my above posts a little better he will see that I have written php code that is in a php file, not in javascript.
> Next is that in general (IMHO) it is best to code your php such that it uses relative paths.
This observation is more to the point. I'm glad you have expressed your opinion on this. But it doesn't work that easily. PHP includes often require absolute paths, especially if you're having to do an include across subdirectories that are under different directories. It gets a little complicated to have to do chdir()'s in order to be able to do a php include. I think a good solution to php includes is setting your include path in the environment by use of set_include_path(). But this requires giving a path from root, and root means the absolute path in your server hosting. My difficulty is getting this absolute path in different hosting environments in order to be able for example to set the include path with set_include_path. The php environment variables (such as $_SERVER) have different kinds of values in different hosting environments.
I am now thinking that maybe this could be the best possibility: use getcwd() to get the absolute path to the current script, then process this string deleting the last part with the current script filename and the various subdirectories so that I'm left with the correct absolute path to root.
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]