FUDforum
Fast Uncompromising Discussions. FUDforum will get your users talking.

Home » Imported messages » comp.lang.php » php includes and ajax
Show: Today's Messages :: Polls :: Message Navigator
Return to the default flat view Create a new topic Submit Reply
Re: php includes and ajax [message #173106 is a reply to message #173105] Tue, 22 March 2011 00:37 Go to previous messageGo to previous message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
Senior Member
On 3/21/2011 8:06 PM, Lwangaman wrote:
> 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.
>

And I'm saying it would be very simple to create that administrative div
on my own page and submit it. Authorization needs to be checked on
EVERY call. NEVER trust ANYTHING from the client!

>> 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.
>

Sure I've used AJAX in the past. And I'm working on a site using it
right now. But nothing you're doing requires AJAX.

> 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.
>

Maybe you should learn that there are other people in this newsgroup who
know what's going on, too. Many of us know a lot more than you do.
Myself, for instance, I have been programming for over 40 years. I was
doing transactional programming long before the web was even thought of.
And I've been doing web programming for almost 15 years now. I think
I know how it works. As does every person here giving you advice.

I would suggest you NOT talk down to the members. People will rapidly
lose interest in trying to help you.

> 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).
>

See above and please stop trying to impress us with your "intelligence".
You are doing just the opposite.

> 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 understand AJAX quite well - as do a lot of people here. And no, PHP
does NOT pre-process web pages. PHP GENERATES output, which may or may
not be HTML. It then sends it to STDOUT. If this happens to be running
under a web server, that output is sent to the browser.

PHP knows NOTHING about AJAX. All PHP knows is that a request was
received, which initiated a script. The PHP code generates the output
and completes. Period. Whether the request came from AJAX, cURL, a web
browser or a plain TCP/IP connection is completely immaterial.


> 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.
>

It depends on the needs. But there are many downsides also - but that
is off-topic in this newsgroup.

> 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.
>

No one was talking about security of AJAX. But again, you are off topic
in this newsgroup.

> 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.
>

Since PHP knows nothing about AJAX, your question is meaningless. PHP
includes are handled the same way no matter what the source of the request.

>> 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.
>

This has disadvantages also, such as increased load on the server having
to search multiple directories. Not bad if you run a low-volume site,
but if it gets busy and you have a number of directories, it can
increase the load on the server.

Then there is the problem of having the same file name in two or more
directories - and not knowing which one you picked up.

PHP NEVER "requires" absolute paths. I always use paths relative to
$_SERVER['DOCUMENT_ROOT']. That way it's completely portable but all
paths are absolute.

> 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.
>
>

If you want. I've never found a need to do so.

P.S. Please adjust your usenet client to limit your line length to a
reasonable size. Common is around 70 characters.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: PHP Developers needed
Next Topic: Cannot send emails
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Fri Oct 18 04:13:23 GMT 2024

Total time taken to generate the page: 0.04718 seconds