php includes and ajax [message #173087] |
Sun, 20 March 2011 22:16 |
Lwangaman
Messages: 4 Registered: March 2011
Karma: 0
|
Junior Member |
|
|
I've been experimenting with ajax functionality in the past few months, but I'm having different results on different web hosts...
My biggest difficulty has to do with the path for php file includes. Here's my situation:
My CMS defines some functions for checking user permissions in a file called "functions.php" in this path: "/include".
Before enabling certain functionalities on the javascript side (such as administrative buttons in a jquery-ui dialog) I want to check if the user has administrative privileges. So I create a php file for this check, for example I want to check if the user is a news administrator so I name the file "newsadmin.php" and put it in the "/themes/glorioso/ajax" folder.
"/themes/glorioso/ajax/newsadmin.php" does an include of "/include/functions.php", then calls the function that checks whether the current user has news administration privileges; if this returns true I echo out "isnewsadmin", otherwise "isnotnewsadmin".
From my javascript I make an ajax call to "newsadmin.php", if the returned value is "isnewsadmin" I add administrative buttons, otherwise I don't.
My javascript file is in "/themes/glorioso/javascripts/glorioso.js".
When I'm working on a website on the aruba shared hosting (http://www.aruba..it/) I can only get my include to work like this:
<?php
require_once($_SERVER["DOCUMENT_ROOT"]."/include/functions.php");
if (is_news_admin()) { echo "isnewsadmin"; }
else { echo "isnotnewsadmin"; }
?>
This doesn't work on an altervista shared hosting (http://it.altervista.org/). The only way I can get it to work an altervista shared hosting is by changing directories:
<?php
chdir("..");
chdir("..");
chdir("..");
require_once("include/flatnux.php");
if (is_news_admin()) { echo "isnewsadmin"; }
else { echo "isnotnewsadmin"; }
?>
Since I'm trying to write a theme for the Flatnux CMS that anyone else can use, I'd like a "universal solution" that can work for anyone on any webserver.
I suppose I could do a check for file existence before the include:
<?php
if(file_exists($_SERVER["DOCUMENT_ROOT"]."/include/functions.php")){
require_once($_SERVER["DOCUMENT_ROOT"]."/include/flatnux.php");
}
else {
chdir("..");
chdir("..");
chdir("..");
require_once("include/functions.php");
}
if(is_news_admin()){
echo "isnewsadmin";
}
else{
echo "isnotnewsadmin";
}
?>
I'd like to understand better the principles behind this stuff though, if there is a standard way of doing the file includes that'll work on every server in ajax calls...
|
|
|
Re: php includes and ajax [message #173091 is a reply to message #173087] |
Sun, 20 March 2011 23:54 |
Jerry Stuckle
Messages: 2598 Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 3/20/2011 6:16 PM, John D'Orazio wrote:
> I've been experimenting with ajax functionality in the past few months, but I'm having different results on different web hosts...
>
> My biggest difficulty has to do with the path for php file includes. Here's my situation:
>
> My CMS defines some functions for checking user permissions in a file called "functions.php" in this path: "/include".
>
> Before enabling certain functionalities on the javascript side (such as administrative buttons in a jquery-ui dialog) I want to check if the user has administrative privileges. So I create a php file for this check, for example I want to check if the user is a news administrator so I name the file "newsadmin.php" and put it in the "/themes/glorioso/ajax" folder.
> "/themes/glorioso/ajax/newsadmin.php" does an include of "/include/functions.php", then calls the function that checks whether the current user has news administration privileges; if this returns true I echo out "isnewsadmin", otherwise "isnotnewsadmin".
>
> From my javascript I make an ajax call to "newsadmin.php", if the returned value is "isnewsadmin" I add administrative buttons, otherwise I don't.
>
> My javascript file is in "/themes/glorioso/javascripts/glorioso.js".
> When I'm working on a website on the aruba shared hosting (http://www.aruba.it/) I can only get my include to work like this:
> <?php
> require_once($_SERVER["DOCUMENT_ROOT"]."/include/functions.php");
> if (is_news_admin()) { echo "isnewsadmin"; }
> else { echo "isnotnewsadmin"; }
> ?>
>
> This doesn't work on an altervista shared hosting (http://it.altervista.org/). The only way I can get it to work an altervista shared hosting is by changing directories:
>
> <?php
> chdir("..");
> chdir("..");
> chdir("..");
> require_once("include/flatnux.php");
> if (is_news_admin()) { echo "isnewsadmin"; }
> else { echo "isnotnewsadmin"; }
> ?>
>
> Since I'm trying to write a theme for the Flatnux CMS that anyone else can use, I'd like a "universal solution" that can work for anyone on any webserver.
> I suppose I could do a check for file existence before the include:
> <?php
> if(file_exists($_SERVER["DOCUMENT_ROOT"]."/include/functions.php")){
> require_once($_SERVER["DOCUMENT_ROOT"]."/include/flatnux.php");
> }
> else {
> chdir("..");
> chdir("..");
> chdir("..");
> require_once("include/functions.php");
> }
> if(is_news_admin()){
> echo "isnewsadmin";
> }
> else{
> echo "isnotnewsadmin";
> }
> ?>
>
> I'd like to understand better the principles behind this stuff though, if there is a standard way of doing the file includes that'll work on every server in ajax calls...
First of all, NEVER trust something client side. It would be very easy,
for me to change your code to always believe the user is an administrator.
Next, javascript is client-side. PHP is server-side (almost always,
anyway). But javascript on the client cannot include the source code of
a PHP file on the server side. All it can do is get the output of the
PHP script.
The way to do it is to always do any security checks (and input
validation) on the server. Client-side (javascript) can perform some
checks, but they must ALWAYS be backed up by server-side
verification/validation.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
Re: php includes and ajax [message #173094 is a reply to message #173087] |
Mon, 21 March 2011 00:27 |
HaleLOIS
Messages: 10 Registered: December 2010
Karma: 0
|
Junior Member |
|
|
I think I saw in some past pasts that if I answer from Google groups the discussions don't stay under the same thread, so I've just signed up to compgroups (supposing that it's the home to comp.lang.php).
I just wanted to add that relative file paths aren't working for me on ajax requests, which is why I'm trying to get the absolute path.
The optimal solution would be being able to set the php ini include path, like so:
<?php
set_include_path($_SERVER['DOCUMENT_ROOT']."themes/glorioso/include/" . PATH_SEPARATOR . get_include_path() );
?>
But the $_SERVER["DOCUMENT_ROOT"] solution doesn't work on some hosted servers such as altervista.
The value of $_SERVER["DOCUMENT_ROOT"] on altervista is:
"/var/www/html"
but the absolute path to the website root is:
"/membri/"
This "/membri/" subdirectory can only be obtained by two $_SERVER variables, "ORIG_PATH_TRANSLATED" and "SCRIPT_FILENAME" that give something along these lines:
"/membri/consultapg33/themes/glorioso/ajax/newsadmin.php".
The value of $_SERVER["DOCUMENT_ROOT"] on aruba is:
"/web/htdocs/www.parrocchiasanlino.org/home/"
There is no "ORIG_PATH_TRANSLATED" variable, and "SCRIPT_FILENAME" gives:
"/web/htdocs/www.parrocchiasanlino.org/home/themes/glorioso/ajax/flopt.php",
so on aruba they coincide but on altervista they don't.
What's the best way to handle the absolute path taking all this into consideration?
|
|
|
Re: php includes and ajax [message #173095 is a reply to message #173087] |
Mon, 21 March 2011 00:35 |
HaleLOIS
Messages: 10 Registered: December 2010
Karma: 0
|
Junior Member |
|
|
Ok you answered while I was formulating my next post; just wanted to let you know that I am doing user verification client side, for example the div that will be opened by the administrative buttons on the jquery-ui dialog will only exist on the page if you are an administrator. So even if you make the page believe you are an administrator it won't get you anywhere because you'll see buttons that don't actually do anything.
But my problem is more than just user verification.
For example, I have a div where a privileged user can fill out an event to be written to a calendar which is connected to a google calendar via a form submit. Instead of refreshing the page to submit the form I prefer to use ajax, so I have a php file called createEvent.php that has to include the ZEND GDATA libraries in order to submit the event.
And I'm having the same include problems. These includes ARE server side. The ajax request is client side, coming from javascript, but the actual include IS server side because it's in my php file, not in my javascript file.
|
|
|
|
Re: php includes and ajax [message #173097 is a reply to message #173095] |
Mon, 21 March 2011 01:37 |
Jerry Stuckle
Messages: 2598 Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 3/20/2011 8:35 PM, Lwangaman wrote:
> Ok you answered while I was formulating my next post; just wanted to let you know that I am doing user verification client side, for example the div that will be opened by the administrative buttons on the jquery-ui dialog will only exist on the page if you are an administrator. So even if you make the page believe you are an administrator it won't get you anywhere because you'll see buttons that don't actually do anything.
>
> But my problem is more than just user verification.
>
> For example, I have a div where a privileged user can fill out an event to be written to a calendar which is connected to a google calendar via a form submit. Instead of refreshing the page to submit the form I prefer to use ajax, so I have a php file called createEvent.php that has to include the ZEND GDATA libraries in order to submit the event.
> And I'm having the same include problems. These includes ARE server side. The ajax request is client side, coming from javascript, but the actual include IS server side because it's in my php file, not in my javascript file.
>
>
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.
NEVER do verification client-side without server-side verification!
So what is your include problem? You have shown no PHP code so far.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
Re: php includes and ajax [message #173103 is a reply to message #173087] |
Mon, 21 March 2011 12:43 |
Captain Paralytic
Messages: 204 Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Mar 20, 10:16 pm, "John D'Orazio" <donjohn.f...@gmail.com> wrote:
> SNIPPED
> I'd like to understand better the principles behind this stuff though, if there is a standard
> way of doing the file includes that'll work on every server in ajax calls....
I am assuming that you (John D'Orazio) are also Lwangaman.
The first thing to do is to FORGET ABOUT AJAX!!! I am not saying this
because you should not use it, but because php knows nothing about
AJAX. The server does not know whether the request came from an AJAX
request or just someone typing the URL in a browser.
Next is that in general (IMHO) it is best to code your php such that
it uses relative paths. That way, all your main programs need to know
is what your application's file structure is and not what your hosting
server looks like.
|
|
|
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: 0
|
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.
|
|
|
Re: php includes and ajax [message #173106 is a reply to message #173105] |
Tue, 22 March 2011 00:37 |
Jerry Stuckle
Messages: 2598 Registered: September 2010
Karma: 0
|
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
==================
|
|
|
Re: php includes and ajax [message #173107 is a reply to message #173087] |
Tue, 22 March 2011 02:15 |
HaleLOIS
Messages: 10 Registered: December 2010
Karma: 0
|
Junior Member |
|
|
I'm not using any kind of client, I've never used usenet before, I'm publishing directly to the compgroups.net/comp.lang.php website. What do you suggest as a usenet client?
Ok ok, I don't want to downtalk anyone, I don't want to impress anyone, and I am sure most of you know a lot more than me about these languages. But I would like to have a meaningful and collaborative conversation that sticks to the point. This means not making rash statements. You say for example:
> But nothing you're doing requires AJAX.
Can I say that this observation is off-topic? The web could exist without AJAX (as it has for a number of years). Does that mean that we shouldn't use AJAX or that I can't use it? As I said, I believe that it makes for a better user experience, and yes according to what it is you have to do. Maybe someone else would decide not to use ajax in certain circumstances, I might decide that I prefer to use it in those circumstances. That's really more of a personal taste I believe. The whole reason the ajax thing came up in my question is because, since the Flatnux CMS builds all pages off of index.php, there usually aren't many difficulties in doing php includes because you're scripts are all basically working in the root directory (within index.php). But when you start doing ajax requests to php files in other subdirectories, the ajax request is treated as a separate page, and you're no longer working from index.php but either from your javascript's path or your "interrogated" php script's path.
I am interested in web security, I do read up on it, it is useful and necessary to take it into account and keep best practices. And I do welcome any useful advice. I don't understand you however when you say:
> And I'm saying it would be very simple to create that administrative div on my own page and submit it.
I don't think we're understanding each other. How can you create it if you don't know what it is? If it's never generated on the page because a php function says that you're not administrator so you're never gonna see it (not because it's hidden, but because it's not there). I'm not trying to provoke anyone, I'm just trying to see if we can try to understand each other. If php is server-side, you don't know what it's processing do you? so you don't know what it's not generating. If it doesn't generate a div, how can you re-create a div that you've never seen and never will see?
So I'm NOT trusting anything from the client, in fact my main verification is done in php and therefore on the server, so that div does not even exist on the client if you're not an administrator. Have I been more exhaustive in my explanation?
It seems to me that I'm being a little petty if I make remarks on some of these statements, but again I think we need to have a collaborative conversation. You state:
> And no, PHP does NOT pre-process web pages
I'm sure I don't need to teach you anything about PHP, in fact I came here to learn something from you. But a statement like yours seems a little petty to me too. Am I wrong or PHP = Hypertext Pre-processor? PHP generates output after it has processed logic on the server. So it does "pre-processes" a page. It processes the content on the server before that generated content is then output to the client. Afterwards javascript can continue processing that output directly on the client browser.
The reason i was long-winded in my last message wasn't because I think I can teach something, it was only to see if we're talking the same language. I think we are talking the same language and saying the same things but some of you like to be a little too picky, that's my impression.
Anyways all of that is pretty much off topic and I probably shouldn't have gone down to pointing these things out.
I really do appreciate your advice as regards my original question: the best practice for doing php includes.
> I always use paths relative to $_SERVER['DOCUMENT_ROOT']. That way it's completely portable but all paths are absolute.
In fact that has been my solution up till now, but just recently I began having problems on the altervista.it web hosting where $_SERVER['DOCUMENT_ROOT'] doesn't correspond to the actual root of the website. It adds a "/members/yourwebsite/" subdirectory between $_SERVER['DOCUMENT_ROOT'] and your actual content, which therefore breaks all your php includes.
Perhaps the best solution could be to stick to the $_SERVER["DOCUMENT_ROOT"] principle, but offer a configuration variable for site administrators that use shared hosting such as altervista.it, where they can indicate any differences applied by their hosting environment. Then I can take that variable into account when I do my includes from $_SERVER['DOCUMENT_ROOT'].
|
|
|
Re: php includes and ajax [message #173109 is a reply to message #173107] |
Tue, 22 March 2011 03:17 |
Jerry Stuckle
Messages: 2598 Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 3/21/2011 10:15 PM, Lwangaman wrote:
> I'm not using any kind of client, I've never used usenet before, I'm publishing directly to the compgroups.net/comp.lang.php website. What do you suggest as a usenet client?
>
Get yourself a real usenet account and a real usenet reader. There are
a number of them around (MS Outlook is probably the worst). And you'll
find accessing usenet directly is much better - there are also
inexpensive or free usenet providers. But you should be asking this in
a usenet-related newsgroup - you'll get better answers.
> Ok ok, I don't want to downtalk anyone, I don't want to impress anyone, and I am sure most of you know a lot more than me about these languages. But I would like to have a meaningful and collaborative conversation that sticks to the point. This means not making rash statements. You say for example:
>> But nothing you're doing requires AJAX.
> Can I say that this observation is off-topic? The web could exist without AJAX (as it has for a number of years). Does that mean that we shouldn't use AJAX or that I can't use it? As I said, I believe that it makes for a better user experience, and yes according to what it is you have to do. Maybe someone else would decide not to use ajax in certain circumstances, I might decide that I prefer to use it in those circumstances. That's really more of a personal taste I believe. The whole reason the ajax thing came up in my question is because, since the Flatnux CMS builds all pages off of index.php, there usually aren't many difficulties in doing php includes because you're scripts are all basically working in the root directory (within index.php). But when you start doing ajax requests to php files in other subdirectories, the ajax request is treated as a separate page, and you're no longer working from index.php but either from your javascript's path or your "interrogated"
php script's path.
>
> I am interested in web security, I do read up on it, it is useful and necessary to take it into account and keep best practices. And I do welcome any useful advice. I don't understand you however when you say:
>
>> And I'm saying it would be very simple to create that administrative div on my own page and submit it.
> I don't think we're understanding each other. How can you create it if you don't know what it is? If it's never generated on the page because a php function says that you're not administrator so you're never gonna see it (not because it's hidden, but because it's not there). I'm not trying to provoke anyone, I'm just trying to see if we can try to understand each other. If php is server-side, you don't know what it's processing do you? so you don't know what it's not generating. If it doesn't generate a div, how can you re-create a div that you've never seen and never will see?
>
All I need to do is see an admin page once and I've got it. That could
even happen if I were to tap the datastream between your client and the
host. Or experiment around a little. Security by obscurity is worse
than no security at all - it gives the APPEARANCE of security but is not
at all secure.
> So I'm NOT trusting anything from the client, in fact my main verification is done in php and therefore on the server, so that div does not even exist on the client if you're not an administrator. Have I been more exhaustive in my explanation?
I understand what you're doing. And it's only security by obscurity.
Please see above.
>
> It seems to me that I'm being a little petty if I make remarks on some of these statements, but again I think we need to have a collaborative conversation. You state:
>> And no, PHP does NOT pre-process web pages
> I'm sure I don't need to teach you anything about PHP, in fact I came here to learn something from you. But a statement like yours seems a little petty to me too. Am I wrong or PHP = Hypertext Pre-processor? PHP generates output after it has processed logic on the server. So it does "pre-processes" a page. It processes the content on the server before that generated content is then output to the client. Afterwards javascript can continue processing that output directly on the client browser.
>
It's not petty at all. "Pre-processing" has a specific meaning in
computer lingo. PHP does not 'pre-process' pages. And PHP generates
output which generally goes straight to the browser. If javascript does
something else, that's done at the browser end.
And yes, I know what PHP stands for. The people who named it would much
rather have a "cure" name than an accurate one. It's one of the many
gripes I have with PHP.
> The reason i was long-winded in my last message wasn't because I think I can teach something, it was only to see if we're talking the same language. I think we are talking the same language and saying the same things but some of you like to be a little too picky, that's my impression.
>
I'm being accurate. Accuracy counts.
> Anyways all of that is pretty much off topic and I probably shouldn't have gone down to pointing these things out.
>
> I really do appreciate your advice as regards my original question: the best practice for doing php includes.
>
>> I always use paths relative to $_SERVER['DOCUMENT_ROOT']. That way it's completely portable but all paths are absolute.
>
> In fact that has been my solution up till now, but just recently I began having problems on the altervista.it web hosting where $_SERVER['DOCUMENT_ROOT'] doesn't correspond to the actual root of the website. It adds a "/members/yourwebsite/" subdirectory between $_SERVER['DOCUMENT_ROOT'] and your actual content, which therefore breaks all your php includes.
Isn't that where your pages lie? That's how a number of inexpensive
hosts work.
And if it isn't, I'd be out of there ASAP. If they can't even get
something as basic as $_SERVER['DOCUMENT_SHORT'] right, it's hard
telling what else they've screwed up.
>
> Perhaps the best solution could be to stick to the $_SERVER["DOCUMENT_ROOT"] principle, but offer a configuration variable for site administrators that use shared hosting such as altervista.it, where they can indicate any differences applied by their hosting environment. Then I can take that variable into account when I do my includes from $_SERVER['DOCUMENT_ROOT'].
>
>
Or find a better shared hosting provider. They're a commodity.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
Re: php includes and ajax [message #173112 is a reply to message #173105] |
Tue, 22 March 2011 06:43 |
Michael Fesser
Messages: 215 Registered: September 2010
Karma: 0
|
Senior Member |
|
|
.oO(Lwangaman)
> 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.
Correct, but if used improperly or too often it may also cause problems.
Partly replacements of a page for example pretty much defeat the purpose
of the browser's back button - you just can't get back the usual way,
but have to use the site's navigation again. A navigation completely
based on AJAX is usually not very user-friendly.
Micha
|
|
|
Re: php includes and ajax [message #173114 is a reply to message #173105] |
Tue, 22 March 2011 10:34 |
Captain Paralytic
Messages: 204 Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Mar 22, 12:06 am, Lwangaman <u...@compgroups.net/> 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..
>
>> 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.
I have used AJAX and I do know what it is useful for and I have tried
to help you by telling you that by talking about AJAX in the context
of a pure php problem (since PHP knows nothing about AJAX) you are
simply muddying the waters.
I do not need a lecture from you about what AJAX is and isn't.
Since you seem not to want help from your betters, I for one am out of
here.
|
|
|
Re: php includes and ajax [message #173115 is a reply to message #173105] |
Tue, 22 March 2011 10:35 |
Tim Streater
Messages: 328 Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In article <tLCdncq0KqK_dRrQnZ2dnUVZ_jGdnZ2d(at)giganews(dot)com>,
Lwangaman <user(at)compgroups(dot)net/> wrote:
[far too much. You'll do a lot better by formulating your questions in a
more succinct manner]
> 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 hope you read Jerry's response - all that the PHP script knows is that
it is running and has access to certain variables. It will have been
invoked by apache or similar.
None of my PHP scripts in these circumstances do anything with web
pages. They take the data they are given, process it one way or another,
and write output (not, in my case, HTML or even XML) to stdout (I use
echo for this). This output is captured by apache (or similar) and
returned to the browser, where JavaScript may be used to examine those
results and decide how to update the page.
As all your posts appear to be hundreds of words long, and I can't be
arsed to read all that, I'm not sure I even know what you are asking.
--
Tim
"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
|
|
|
Re: php includes and ajax [message #173116 is a reply to message #173105] |
Tue, 22 March 2011 10:50 |
Denis McMahon
Messages: 634 Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Mon, 21 Mar 2011 19:06:58 -0500, Lwangaman wrote:
> Getting back to the point: my question is about how server-side php
> includes are to be handled semantically in a php file (<deleted
> irrelevancy>).
You have four choices:
include ("filemname.php");
include_once ("filemname.php");
require ("filemname.php");
require_once ("filemname.php");
For discussion of the implications of the various methods, and various
opinions on which is best, try googling "php include require".
Various people using this group have opinions on these, and they are not
always in agreement.
Rgds
Denis McMahon
|
|
|
Re: php includes and ajax [message #173129 is a reply to message #173116] |
Wed, 23 March 2011 12:15 |
Thomas 'PointedEars'
Messages: 701 Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Denis McMahon wrote:
> Lwangaman wrote:
>> Getting back to the point: my question is about how server-side php
>> includes are to be handled semantically in a php file (<deleted
>> irrelevancy>).
>
> You have four choices:
>
> include ("filemname.php");
> include_once ("filemname.php");
> require ("filemname.php");
> require_once ("filemname.php");
The parentheses are not required; those statements are not function calls
and should not misguidingly be written as such. See also the PEAR Coding
Standards.
The double quotes should be single quotes since there is no variable
expansion required, but that is just my preference.
These are, however, not the only choices and they are not always the best
ones; indeed, the PEAR2 Coding Standards Rules require those statements to
be omitted from PEAR modules. (They have, however, expired by on
2008-03-01.)
<http://pear.php.net/manual/en/standards.including.php>
<http://pear.php.net/manual/en/pear2cs.rules.php>
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
|
|
|