[snip]
I made one. Here:
// Alter variables for the versions prior to 4.1.0
// NOTE: $_REQUEST global variable is NOT supported.
if(strnatcasecmp('4.1.0', PHP_VERSION)>=0) {
foreach(Array(
'_GET' => 'HTTP_GET_VARS'
On Fri, 4 Oct 2002 20:50:32 +1000
Adam Royle <[EMAIL PROTECTED]> wrote:
> Hi All,
>
> I have been a subscriber of php-db for quite some time, and I have seen
> MANY ppl ask why their variables aren't being passed though, etc, due
> to register_globals, etc, blah blah blah
>
> I have kept my
On 15 Feb 2002, at 17:04, Philip J. Newman wrote:
> WHo really cares, if it works it don't matter what they call it.
In response to:
> > > On that same topic, *why* do people name files with both .inc and
> > > .php?
> > > Your .inc file has PHP code in it, right? Why not just call it
> > >
On Friday, February 15, 2002, at 12:35 PM, J Smith wrote:
> The only real security problem is that if the file isn't parsed and
> it's in
> the web server's document path, somebody can just go to
> http://www.example.com/include/config.inc and see the entire contents in
> plaintext -- password
On 15 Feb 2002 at 10:50, Michael Kimsal wrote:
> Erik Price wrote:
> >
> > On Thursday, February 14, 2002, at 04:40 PM, Michael Kimsal wrote:
> >
> >> On that same topic, *why* do people name files with both .inc and
> >> .php? Your .inc file has PHP code in it, right? Why not just call it
Well, .inc seems to be so common as to be a standard practice. At the very
least, the real issue is education on the need to protect included files
anyway so that they can't be accessed directly.
c
--
Chris Lott
http://www.chrislott.org/
--
PHP General Mailing List (http://www.php.net/)
To unsu
The only real security problem is that if the file isn't parsed and it's in
the web server's document path, somebody can just go to
http://www.example.com/include/config.inc and see the entire contents in
plaintext -- passwords and config options galore. However, sticking those
.inc files out
On Friday, February 15, 2002, at 10:50 AM, Michael Kimsal wrote:
> That's great for you that you have that luxury, as do I, but not
> everyone has access to their server's conf file.
Whether or not you want to call administrating a web server a luxury is
debatable -- I'm learning new things
Erik Price wrote:
>
> On Thursday, February 14, 2002, at 04:40 PM, Michael Kimsal wrote:
>
>> On that same topic, *why* do people name files with both .inc and
>> .php? Your .inc file has PHP code in it, right? Why not just call it
>> .php and
>> spare the server reconfiguration. If knowin
On Thursday, February 14, 2002, at 04:40 PM, Michael Kimsal wrote:
> On that same topic, *why* do people name files with both .inc and
> .php? Your .inc file has PHP code in it, right? Why not just call it
> .php and
> spare the server reconfiguration. If knowing which files are "include"
It does to a certain extent. If you're writing code that you're expecting
others to see and use, you should try to be consistent and follow
convention. If you write up a large project in C++ and suddenly start
naming header files with a ".doc" extension, somebody's going to get
confused.
Of
WHo really cares, if it works it don't matter what they call it.
- Original Message -
From: "Peter J. Schoenster" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, February 15, 2002 5:36 PM
Subject: Re: [PHP] good practice
> On 14 Feb 2002,
On 14 Feb 2002, at 16:40, Michael Kimsal wrote:
> On that same topic, *why* do people name files with both .inc and
> .php?
> Your .inc file has PHP code in it, right? Why not just call it .php
> and
> spare the server reconfiguration. If knowing which files are
> "include" files (long tim
On 14 Feb 2002, at 16:26, J Smith wrote:
>
> Using "global" in the global scope (i.e. "global $Config;") does
> nothing. If something is declared in the global scope of a file and
> then included into another file, it's still global. You don't need to
> actually say "global $whatever" unless you
Or put them outside of the web server's document hierarchy.
I'd feel safer with that than naming them with a .php extension. If they
can still be executed by PHP using a GET request, then something could
still be output to a user's browser. (Likely unintentionally, of course,
but still...) P
J Smith wrote:
> Also, if you're including a file named "CONFIG.inc" from the same directory
> as the script itself, please, please tell me you have your web server set
> up not to serve CONFIG.inc to the outside world. (i.e. you have a .htaccess
> file or something to send DENY to a request fo
Using "global" in the global scope (i.e. "global $Config;") does nothing.
If something is declared in the global scope of a file and then included
into another file, it's still global. You don't need to actually say
"global $whatever" unless you're in a function.
Also, if you're including a f
What I do is use templates to separate the html from the php. So I end up with (at
least) 2 files per page, one the template; the other the html. If you have tables,
then you need templates for the rows. My model is basically:
If ("POST" == $HTTP_SERVER_VARS['REQUEST_METHOD']) {
// do data val
On Thu, 2002-02-14 at 11:09, James Taylor wrote:
> Can someone recommend a better method for doing something like the following?
> All of my programs are written like this, but it's really poor form
> considering I'm not predeclaring my variables, etc. Only thing I can really
> think of is to
On 14 Feb 2002, at 11:09, James Taylor wrote:
> Can someone recommend a better method for doing something like the
> following? All of my programs are written like this, but it's really
> poor form considering I'm not predeclaring my variables, etc. Only
> thing I can really think of is to assi
I don't understand what you are trying to do...
If you need to verify whether the page has already been submitted to
itself, you can test any of the form variables using isset(). For
example:
";
echo "";
echo "";
}
?>
You can also pass the data back int
21 matches
Mail list logo
