| 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:
|
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
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]