php-general Digest 4 Dec 2006 21:04:13 -0000 Issue 4496
Topics (messages 245475 through 245496):
Re: problem with register globals on new server
245475 by: Tony Marston
Re: <?=$var?> on OS X
245476 by: Dotan Cohen
Re: hiding passwd in cmdlines that appear in the process list
245477 by: Jochem Maas
245479 by: tg-php.gryffyndevelopment.com
245481 by: T.Lensselink
245490 by: Jochem Maas
245491 by: Jochem Maas
Sending E-mail
245478 by: Janet Smith
245480 by: T.Lensselink
245484 by: Jochem Maas
245488 by: Janet Smith
245489 by: Jochem Maas
Re: Random pictures - not twice
245482 by: tedd
245495 by: Gustav Wiberg
Re: security and .htaccess
245483 by: tedd
245487 by: Frank Reichenbacher, Bio-Concepts, Inc.
245494 by: tedd
Re: EZ array problem - What's wrong with my brain?
245485 by: Jochem Maas
245486 by: Jochem Maas
245492 by: Martin Alterisio
illegal characters
245493 by: M.Ozan Hazer
Distinguishing between a mouse click and a refresh?
245496 by: Mark London
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
""Richard Lynch"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On Sun, December 3, 2006 5:22 am, Tony Marston wrote:
>>
>> ""Richard Lynch"" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]
>>> On Sat, December 2, 2006 5:31 am, Tony Marston wrote:
>>> I think it is quite possible for a sysAdmin to configure
>>> AllowOverride
>>> and .htaccess in such a way that "too much" latitude is granted to
>>> their clients to access each others' data...
>>
>> I disagree. What directives can give you access to other people's
>> data?
>
> I believe I once managed to track down a bit of data using
> FollowSymlink for a client that wasn't available otherwise.
>
> In our case, it was data they actually had a legal/moral right to see,
> but technical snafus were in the way.
>
> Presumably all the other combinations of AllowOverride are not there
> just for the sheer fun of complexity by the Apache team.
>
> I'm betting that at least some of them have security trade-offs in
> mind, and are not just about random features nor performance.
>
>>> And there is alleged to be a significant performance loss to
>>> .htaccess, so a hurried sysAdmin may have over-simplified their
>>> decision process...
>>
>> "Alleged" is the word. Where are the figures to support this? While
>> there is
>> "some" performance loss, with the speed of today;'s PCs can this
>> really be
>> considered as "significant"?
>
> I don't have benchmarks.
>
> Do you?
No, otherwise I would have quoted them. Generally speaking when people say
that "X is inefficient or bad for performance" all they can prove is that if
something extra is done then it takes extra processing time to perform that
extra work, and they usually quote from an out-of-date source. While the
time taken for Apace to process an htaccess file may have been significant
on a 1Mhz processor it is barely noticeable on a 3Ghz processor.
If the time taken to process an htaccess file on one of today's processors
adds 0.000001 seconds to a page's load time, would that be regarded as
"significant"? Would this be a small price to pay for the advantage of being
able to change Apache's configuration with an htaccess file?
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
--- End Message ---
--- Begin Message ---
On 01/12/06, Michelle Konzack <[EMAIL PROTECTED]> wrote:
Am 2006-11-27 03:28:08, schrieb Dotan Cohen:
> Actually, it does. He can global replace "<?=" with "<?php print" and
I think you meen: replace "<?= $" with "<?php print $"
Yes, that's what I meant.
Dotan Cohen
http://what-is-what.com/what_is/bios.html
--- End Message ---
--- Begin Message ---
[EMAIL PROTECTED] wrote:
> If you did use ENV to set the username and password, you could always unset
> it using the same method after you ran the mysql command. So it'd only be
> exposed for a very brief period of time and slightly less accessible than
> just running a process list.
>
indeed I do the following directly after the relevant call to exec() :
putenv('MYSQL_PLESK_PWD=doreallythinkIwouldleavethispwdfloatingaroundinashellenv?');
> It still falls under the category of "security through obscurity" which isn't
> a best practice scenario. But I can't think of another way to run mysql
> under these circumstances that's any better.
but given that the ENV var is only available to the shell php in currently
running in (and any subshells) so
the script is only vulnerable to mistakes/attacks from 'inside' the script -
basically I'm assuming that
whatever is stored in the ENV of a shell is not accessible/visible to other
users on the given system.
is that assumption correct?
>
> -TG
>
> = = = Original message = = =
>
> On Thu, November 30, 2006 12:29 pm, Edwin Barrios wrote:
>> This is not triue because a shell vars declered on a shell is only
>> exposed
>> to its subshells, that means that only exec's and system functions
>> calls
>> into the php itself resive those vars declared into the php !
>>
>> You can see this argument in the following code
>>
>> <?php
>> error_reporting(E_ALL);
>>
>>
>> echo "OLD <pre>";
>> system("env");
>> echo "</pre>";
>>
>> putenv("DBNAME=sidf");
>> putenv("DBUSER=p");
>> putenv("DBPASSWD=p");
>>
>> echo "NEW <pre>";
>> system("env");
>> echo "</pre>";
>>
>> ?>
>>
>> and reloading these a couple of times.
>
> My point was that somebody who was doing:
> system("env");
> in a different part of the script, to debug something else, will
> expose the password, probably without even realizing it.
>
--- End Message ---
--- Begin Message ---
You'd assume those ENV variables are secure.. or secure "enough". I know
there's no such thing as perfect security, but I still wonder if there's a
better way.
Although at this point, if there was a way to read other process/subprocess ENV
variables, it'd most likely be something an attacker would have to get at by
being fairly close to the system (trojan installed as root and exploiting an OS
bug that allowed access to ENV variables from other processes for example). So
I'm guessing this is about as secure as you're going to get for now.
The problem still bugs me though.. hah.
-TG
= = = Original message = = =
[EMAIL PROTECTED] wrote:
> If you did use ENV to set the username and password, you could always unset
> it using the same method after you ran the mysql command. So it'd only be
> exposed for a very brief period of time and slightly less accessible than
> just running a process list.
>
indeed I do the following directly after the relevant call to exec() :
putenv('MYSQL_PLESK_PWD=doreallythinkIwouldleavethispwdfloatingaroundinashellenv?');
> It still falls under the category of "security through obscurity" which isn't
> a best practice scenario. But I can't think of another way to run mysql
> under these circumstances that's any better.
but given that the ENV var is only available to the shell php in currently
running in (and any subshells) so
the script is only vulnerable to mistakes/attacks from 'inside' the script -
basically I'm assuming that
whatever is stored in the ENV of a shell is not accessible/visible to other
users on the given system.
is that assumption correct?
>
> -TG
___________________________________________________________
Sent by ePrompter, the premier email notification software.
Free download at http://www.ePrompter.com.
--- End Message ---
--- Begin Message ---
Doesn't it show up on the phpinfo(); page under "Environment" when
using the putenv(); call?
On Mon, 04 Dec 2006 13:55:56 +0100, Jochem Maas <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>> If you did use ENV to set the username and password, you could always
> unset it using the same method after you ran the mysql command. So it'd
> only be exposed for a very brief period of time and slightly less
> accessible than just running a process list.
>>
>
> indeed I do the following directly after the relevant call to exec() :
>
>
> putenv('MYSQL_PLESK_PWD=doreallythinkIwouldleavethispwdfloatingaroundinashellenv?');
>
>> It still falls under the category of "security through obscurity" which
> isn't a best practice scenario. But I can't think of another way to run
> mysql under these circumstances that's any better.
>
> but given that the ENV var is only available to the shell php in currently
> running in (and any subshells) so
> the script is only vulnerable to mistakes/attacks from 'inside' the script
> - basically I'm assuming that
> whatever is stored in the ENV of a shell is not accessible/visible to
> other users on the given system.
>
> is that assumption correct?
>
>>
>> -TG
>>
>> = = = Original message = = =
>>
>> On Thu, November 30, 2006 12:29 pm, Edwin Barrios wrote:
>>> This is not triue because a shell vars declered on a shell is only
>>> exposed
>>> to its subshells, that means that only exec's and system functions
>>> calls
>>> into the php itself resive those vars declared into the php !
>>>
>>> You can see this argument in the following code
>>>
>>> <?php
>>> error_reporting(E_ALL);
>>>
>>>
>>> echo "OLD <pre>";
>>> system("env");
>>> echo "</pre>";
>>>
>>> putenv("DBNAME=sidf");
>>> putenv("DBUSER=p");
>>> putenv("DBPASSWD=p");
>>>
>>> echo "NEW <pre>";
>>> system("env");
>>> echo "</pre>";
>>>
>>> ?>
>>>
>>> and reloading these a couple of times.
>>
>> My point was that somebody who was doing:
>> system("env");
>> in a different part of the script, to debug something else, will
>> expose the password, probably without even realizing it.
>>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
T.Lensselink wrote:
> Doesn't it show up on the phpinfo(); page under "Environment" when
> using the putenv(); call?
I'd be surprised - firstly I'm not dealing with 'pages' because the code
in question constitutes a cmdline script that only runs with the CLI version
of php; secondly the putenv() call doesn't occur in any script that calls
phpinfo()
if I'm wrong then I guess I should reconsider a career as a Whack-A-Mole or
something ;-)
>
> On Mon, 04 Dec 2006 13:55:56 +0100, Jochem Maas <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] wrote:
>>> If you did use ENV to set the username and password, you could always
>> unset it using the same method after you ran the mysql command. So it'd
>> only be exposed for a very brief period of time and slightly less
>> accessible than just running a process list.
>> indeed I do the following directly after the relevant call to exec() :
>>
>>
>> putenv('MYSQL_PLESK_PWD=doreallythinkIwouldleavethispwdfloatingaroundinashellenv?');
>>
>>> It still falls under the category of "security through obscurity" which
>> isn't a best practice scenario. But I can't think of another way to run
>> mysql under these circumstances that's any better.
>>
>> but given that the ENV var is only available to the shell php in currently
>> running in (and any subshells) so
>> the script is only vulnerable to mistakes/attacks from 'inside' the script
>> - basically I'm assuming that
>> whatever is stored in the ENV of a shell is not accessible/visible to
>> other users on the given system.
>>
>> is that assumption correct?
>>
>>> -TG
>>>
>>> = = = Original message = = =
>>>
>>> On Thu, November 30, 2006 12:29 pm, Edwin Barrios wrote:
>>>> This is not triue because a shell vars declered on a shell is only
>>>> exposed
>>>> to its subshells, that means that only exec's and system functions
>>>> calls
>>>> into the php itself resive those vars declared into the php !
>>>>
>>>> You can see this argument in the following code
>>>>
>>>> <?php
>>>> error_reporting(E_ALL);
>>>>
>>>>
>>>> echo "OLD <pre>";
>>>> system("env");
>>>> echo "</pre>";
>>>>
>>>> putenv("DBNAME=sidf");
>>>> putenv("DBUSER=p");
>>>> putenv("DBPASSWD=p");
>>>>
>>>> echo "NEW <pre>";
>>>> system("env");
>>>> echo "</pre>";
>>>>
>>>> ?>
>>>>
>>>> and reloading these a couple of times.
>>> My point was that somebody who was doing:
>>> system("env");
>>> in a different part of the script, to debug something else, will
>>> expose the password, probably without even realizing it.
>>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>
--- End Message ---
--- Begin Message ---
[EMAIL PROTECTED] wrote:
> You'd assume those ENV variables are secure.. or secure "enough". I know
> there's no such thing as perfect security, but I still wonder if there's a
> better way.
>
> Although at this point, if there was a way to read other process/subprocess
> ENV variables, it'd most likely be something an attacker would have to get at
> by being fairly close to the system (trojan installed as root and exploiting
> an OS bug that allowed access to ENV variables from other processes for
> example). So I'm guessing this is about as secure as you're going to get for
> now.
thanks - nice to have a few extra brains executing this 'thought experiment'
>
> The problem still bugs me though.. hah.
yeah it niggles a bit. I keep hunting about now and again to see if I can learn
how
seasoned shell scripters tackle such security issues - undoubtedly I'm not the
first to come
accross these issues, I am after a very small hobbit standing on the shoulders
of very tall ents.
>
> -TG
>
> = = = Original message = = =
>
> [EMAIL PROTECTED] wrote:
>> If you did use ENV to set the username and password, you could always unset
>> it using the same method after you ran the mysql command. So it'd only be
>> exposed for a very brief period of time and slightly less accessible than
>> just running a process list.
>>
>
> indeed I do the following directly after the relevant call to exec() :
>
>
> putenv('MYSQL_PLESK_PWD=doreallythinkIwouldleavethispwdfloatingaroundinashellenv?');
>
>> It still falls under the category of "security through obscurity" which
>> isn't a best practice scenario. But I can't think of another way to run
>> mysql under these circumstances that's any better.
>
> but given that the ENV var is only available to the shell php in currently
> running in (and any subshells) so
> the script is only vulnerable to mistakes/attacks from 'inside' the script -
> basically I'm assuming that
> whatever is stored in the ENV of a shell is not accessible/visible to other
> users on the given system.
>
> is that assumption correct?
>
>> -TG
>
>
> ___________________________________________________________
> Sent by ePrompter, the premier email notification software.
> Free download at http://www.ePrompter.com.
>
.
--- End Message ---
--- Begin Message ---
We have an application using PHP. If users have forgotten their
password, they click on the link 'Forgot Password' and enter this e-mail
address. This is suppose to send their new password to the e-mail
address provided. We can not get the e-mail to be sent. I have changed
the php.ini file to include the SMTP, the sendmail_from and the
sendmail_path. Does anyone have any suggestions as to what else I need
to look at?
Thanks
Jan Smith
Programmer Analyst
Indiana State University
Terre Haute, Indiana
Phone: (812) 237-8593
Email: [EMAIL PROTECTED]
*******************************************************************************************
This email, and any attachments, thereto, is intended only for use by
the addressee(s) named herein and may contain privileged and/or
confidential information. If you are not the intended recipient of this
email, you are hereby notified that any dissemination, distribution or
copying of this email, and any attachments thereto, is strictly
prohibited.
*******************************************************************************************
--- End Message ---
--- Begin Message ---
Without any error messages it will be hard to resolve..
Try to provide some more information about the problem.
On Mon, 04 Dec 2006 09:11:05 -0500, "Janet Smith" <[EMAIL PROTECTED]> wrote:
> We have an application using PHP. If users have forgotten their
> password, they click on the link 'Forgot Password' and enter this e-mail
> address. This is suppose to send their new password to the e-mail
> address provided. We can not get the e-mail to be sent. I have changed
> the php.ini file to include the SMTP, the sendmail_from and the
> sendmail_path. Does anyone have any suggestions as to what else I need
> to look at?
>
> Thanks
>
> Jan Smith
> Programmer Analyst
> Indiana State University
> Terre Haute, Indiana
> Phone: (812) 237-8593
> Email: [EMAIL PROTECTED]
>
> *******************************************************************************************
> This email, and any attachments, thereto, is intended only for use by
> the addressee(s) named herein and may contain privileged and/or
> confidential information. If you are not the intended recipient of this
> email, you are hereby notified that any dissemination, distribution or
> copying of this email, and any attachments thereto, is strictly
> prohibited.
> *******************************************************************************************
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
Janet Smith wrote:
> We have an application using PHP. If users have forgotten their
> password, they click on the link 'Forgot Password' and enter this e-mail
> address. This is suppose to send their new password to the e-mail
> address provided. We can not get the e-mail to be sent. I have changed
> the php.ini file to include the SMTP, the sendmail_from and the
> sendmail_path. Does anyone have any suggestions as to what else I need
> to look at?
what is the error?
what is the code that tries to send the email?
what are the relevant php.ini settings set to?
what is your OS, php version, etc?
do you have a net connection?
can you send email from the cmdline?
give us this info and maybe we can provide a solution.
other than that I can only suggest looking at the moon - it won't solve
the problem, and I don't think the moon has a 'look at me' requirement,
but it is nice to do.
>
> Thanks
>
> Jan Smith
> Programmer Analyst
> Indiana State University
> Terre Haute, Indiana
> Phone: (812) 237-8593
> Email: [EMAIL PROTECTED]
>
> *******************************************************************************************
> This email, and any attachments, thereto, is intended only for use by
> the addressee(s) named herein and may contain privileged and/or
> confidential information. If you are not the intended recipient of this
> email, you are hereby notified that any dissemination, distribution or
> copying of this email, and any attachments thereto, is strictly
> prohibited.
> *******************************************************************************************
>
--- End Message ---
--- Begin Message ---
I wasn't really sure where to start looking, but I think I have enough
information that I can go and look at how we have things set up. I will
try to provide more information as I find it.
Thanks
>>> Jochem Maas <[EMAIL PROTECTED]> 12/4/2006 10:42 AM >>>
Janet Smith wrote:
> We have an application using PHP. If users have forgotten their
> password, they click on the link 'Forgot Password' and enter this
e-mail
> address. This is suppose to send their new password to the e-mail
> address provided. We can not get the e-mail to be sent. I have
changed
> the php.ini file to include the SMTP, the sendmail_from and the
> sendmail_path. Does anyone have any suggestions as to what else I
need
> to look at?
what is the error?
what is the code that tries to send the email?
what are the relevant php.ini settings set to?
what is your OS, php version, etc?
do you have a net connection?
can you send email from the cmdline?
give us this info and maybe we can provide a solution.
other than that I can only suggest looking at the moon - it won't
solve
the problem, and I don't think the moon has a 'look at me'
requirement,
but it is nice to do.
>
> Thanks
>
> Jan Smith
> Programmer Analyst
> Indiana State University
> Terre Haute, Indiana
> Phone: (812) 237-8593
> Email: [EMAIL PROTECTED]
>
>
*******************************************************************************************
> This email, and any attachments, thereto, is intended only for use
by
> the addressee(s) named herein and may contain privileged and/or
> confidential information. If you are not the intended recipient of
this
> email, you are hereby notified that any dissemination, distribution
or
> copying of this email, and any attachments thereto, is strictly
> prohibited.
>
*******************************************************************************************
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
Janet Smith wrote:
> I wasn't really sure where to start looking, but I think I have enough
> information that I can go and look at how we have things set up. I will
> try to provide more information as I find it.
chances are that the following function is being used.
http://php.net/mail
you should really make sure sending email from the cmdline works before
digging deeper into php - it maybe your sendmail (or alternative tool) itself
is borked (in which case php won't be able to use it to send any email!).
smtp and smtp_port are ini settings that are only valid for windows,
I have no idea if setting them in a *nix php installation will cause problems
or not.
>
> Thanks
>
>>>> Jochem Maas <[EMAIL PROTECTED]> 12/4/2006 10:42 AM >>>
> Janet Smith wrote:
>> We have an application using PHP. If users have forgotten their
>> password, they click on the link 'Forgot Password' and enter this
> e-mail
>> address. This is suppose to send their new password to the e-mail
>> address provided. We can not get the e-mail to be sent. I have
> changed
>> the php.ini file to include the SMTP, the sendmail_from and the
>> sendmail_path. Does anyone have any suggestions as to what else I
> need
>> to look at?
>
> what is the error?
> what is the code that tries to send the email?
> what are the relevant php.ini settings set to?
> what is your OS, php version, etc?
> do you have a net connection?
> can you send email from the cmdline?
>
> give us this info and maybe we can provide a solution.
>
> other than that I can only suggest looking at the moon - it won't
> solve
> the problem, and I don't think the moon has a 'look at me'
> requirement,
> but it is nice to do.
>
>> Thanks
>>
>> Jan Smith
>> Programmer Analyst
>> Indiana State University
>> Terre Haute, Indiana
>> Phone: (812) 237-8593
>> Email: [EMAIL PROTECTED]
>>
>>
> *******************************************************************************************
>> This email, and any attachments, thereto, is intended only for use
> by
>> the addressee(s) named herein and may contain privileged and/or
>> confidential information. If you are not the intended recipient of
> this
>> email, you are hereby notified that any dissemination, distribution
> or
>> copying of this email, and any attachments thereto, is strictly
>> prohibited.
>>
> *******************************************************************************************
>
--- End Message ---
--- Begin Message ---
At 11:20 PM +0100 12/3/06, Gustav Wiberg wrote:
Hi there!
I have created a script the generates random pictures...
-snip-
With this above script the same picture can be shown twice. Is there
any smart way of avoiding this without having to rely on
cookies/sessionids?
Random does mean it can happen more than once. I think what you want
is more along a shuffle. Look into the array function "shuffle".
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
----- Original Message -----
From: "tedd" <[EMAIL PROTECTED]>
To: "Gustav Wiberg" <[EMAIL PROTECTED]>; "PHP General"
<[email protected]>
Sent: Monday, December 04, 2006 4:15 PM
Subject: Re: [PHP] Random pictures - not twice
At 11:20 PM +0100 12/3/06, Gustav Wiberg wrote:
Hi there!
I have created a script the generates random pictures...
-snip-
With this above script the same picture can be shown twice. Is there any
smart way of avoiding this without having to rely on cookies/sessionids?
Random does mean it can happen more than once. I think what you want is
more along a shuffle. Look into the array function "shuffle".
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Hi there!
Ok, thanx! I will check the function out :-)
Best regards
Gsutav Wiberg
http://www.stammis.com/ - Stammis Internet - pedigrees on the net
--- End Message ---
--- Begin Message ---
At 5:46 PM -0600 12/3/06, Richard Lynch wrote:
On Sun, December 3, 2006 9:57 am, tedd wrote:
> But, the "_vit_pvt" folder is not apparent. I can't get to it -- is
> this a host file that only they can access, or is there a secret
> handshake I need to get to it, or what?
That's a bull-crap made-up directory reference that FrontPage or
something of that ilk added because everybody uses FrontPage, and
everybody uses their lame-brained "security" layout of weird directory
names.
Replace it with a real AuthUserFile reference.
At 8:57 PM -0700 12/3/06, Frank Reichenbacher wrote:
That is the MS FrontPage auth system. Directories beginning with _
underscores cannot be viewed in your browser. Unless you want to
dump FrontPage, you do not want to be messing with this setup.
If you can't view these directories in FrontPage, it's because you
do not have the website set to show hidden files. Tools>Site
Settings.
Ahhh, thanks -- so it's a FrontPage phenomena. I was wondering about
that. I've heard enough bad things about FrontPage to shy away from
that.
I've used both .htacess (AuthUserFile ) and pulling a md5 encrypted
password from MySQL -- is one method more secure than another or are
they both about the same?
Opinions?
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
> -----Original Message-----
> From: tedd [mailto:[EMAIL PROTECTED]
> Sent: Monday, December 04, 2006 08:29
> To: [email protected]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: [PHP] security and .htaccess
>
<snip>
>
> At 8:57 PM -0700 12/3/06, Frank Reichenbacher wrote:
> >That is the MS FrontPage auth system. Directories beginning with _
> >underscores cannot be viewed in your browser. Unless you want to
> >dump FrontPage, you do not want to be messing with this setup.
> >
> >If you can't view these directories in FrontPage, it's because you
> >do not have the website set to show hidden files. Tools>Site
> >Settings.
>
> Ahhh, thanks -- so it's a FrontPage phenomena. I was wondering about
> that. I've heard enough bad things about FrontPage to shy away from
> that.
>
> I've used both .htacess (AuthUserFile ) and pulling a md5 encrypted
> password from MySQL -- is one method more secure than another or are
> they both about the same?
I can't comment on the last question, but before you do anything, contact
your hosting company and tell them to uninstall the FrontPage extensions
that are currently supposed to be managing your content. It's about 10MB
worth of cgi. It will (I think) return access control to .htaccess and
.htpasswd and will alter the .htaccess to the default security. Otherwise
you will be hacking up the whole structure piece-by-piece.
I use FrontPage to manage several websites, but there are some things that
it gets in the way of since my servers are all UNIX.
Frank
>
> Opinions?
>
> tedd
> --
> -------
> http://sperling.com http://ancientstones.com http://earthstones.com
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
At 8:46 AM -0700 12/4/06, Frank Reichenbacher, Bio-Concepts, Inc. wrote:
> -----Original Message-----
From: tedd [mailto:[EMAIL PROTECTED]
Sent: Monday, December 04, 2006 08:29
To: [email protected]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: [PHP] security and .htaccess
<snip>
At 8:57 PM -0700 12/3/06, Frank Reichenbacher wrote:
>That is the MS FrontPage auth system. Directories beginning with _
>underscores cannot be viewed in your browser. Unless you want to
>dump FrontPage, you do not want to be messing with this setup.
>
>If you can't view these directories in FrontPage, it's because you
>do not have the website set to show hidden files. Tools>Site
>Settings.
Ahhh, thanks -- so it's a FrontPage phenomena. I was wondering about
that. I've heard enough bad things about FrontPage to shy away from
that.
I've used both .htacess (AuthUserFile ) and pulling a md5 encrypted
password from MySQL -- is one method more secure than another or are
they both about the same?
I can't comment on the last question, but before you do anything, contact
your hosting company and tell them to uninstall the FrontPage extensions
that are currently supposed to be managing your content. It's about 10MB
worth of cgi. It will (I think) return access control to .htaccess and
.htpasswd and will alter the .htaccess to the default security. Otherwise
you will be hacking up the whole structure piece-by-piece.
I use FrontPage to manage several websites, but there are some things that
it gets in the way of since my servers are all UNIX.
Frank
Frank:
I appreciate the advice and I would uninstall FrontPage (have done so
on other sites) if I were the lead programmer in this deal. However,
sharper minds than mine apparently know better.
I've looked at the project in question and with over 16,500 files,
I've decided to pass. Sometimes I just don't understand why people
make things so hard on themselves.
Thanks to all.
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
Youri LACAN-BARTLEY wrote:
> Hi Jochem,
>
> I meant "overly-complicated" in this specific context.
> If each key of this array is going to contain only one value why not
> reduce the array to something like this :
>
> array(1) {
> ["1.2"]=>
> array(2) {
> ["code"]=> string(3) "111"
> ["status"]=> string(3) "new"
> }
> }
>
> That's all I was referring to ...
ah yes - I can see your point!
>
> Jochem Maas wrote:
>> Youri LACAN-BARTLEY wrote:
>>> Well, I've only just fallen out of bed, but I'd say you'd be able to
>>> access it via $var[0][0][0] as in $var["1.2"]["code"][0] to change 111
>>> to something else and $var["1.2"]["status"][0] to set/change "new".
>>>
>>> I must say this looks like an overly complicated array for what it
>>> serves. A little OOP could come in handy to organize all that in more
>>> friendly and efficient way ...
>> efficient? overly-complicated?
>>
>> php arrays are made for stuff like this.
>>
>>> Brian Dunning wrote:
>>>> var_dump() gives me this:
>>>>
>>>> array(1) {
>>>> ["1.2"]=>
>>>> array(2) {
>>>> ["code"]=>
>>>> array(1) {
>>>> [0]=>
>>>> string(3) "111"
>>>> }
>>>> ["status"]=>
>>>> array(1) {
>>>> [0]=>
>>>> string(3) "new"
>>>> }
>>>> }
>>>> }
>>>>
>>>> I'm trying to set a variable to that "1.2". Shouldn't I be able to get
>>>> it with $var = $arr[0][0]?
>>>>
>>>> --PHP General Mailing List (http://www.php.net/)
>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>
>
--- End Message ---
--- Begin Message ---
Richard Lynch wrote:
> On Fri, December 1, 2006 9:28 am, Ray Hauge wrote:
>> I forgot to mention that you won't be able to use "0", "1", etc. as
>> PHP
>> will convert those to integers. If you do use them, then they will
>> replace [0] with whatever you put in there, and if you are using the
>> references, it will replace both instances with your new ["0"]
>
> You can type-cast to (string) to force a string key.
>
> $foo[(string) '1'] = 'foo';
>
> should, I think, have a string key...
>
> At least I know for sure that it works for float keys...
>
> You'll have to try it and see for '1' -- I could be way off base.
in cases whether the key you are 'looking up' is numeric php doesn't
care whether you use an integer or string - as far as php is concerned
"1" and 1 point to exactly the same array item:
php -r '$v = array("foo","bar"); var_dump($v["0"],$v[0], $v["1"], $v[1]);'
I find this quite handy - though it does help to actually know about this
particular behaviour :-)
>
--- End Message ---
--- Begin Message ---
2006/11/30, Brian Dunning <[EMAIL PROTECTED]>:
var_dump() gives me this:
array(1) {
["1.2"]=>
array(2) {
["code"]=>
array(1) {
[0]=>
string(3) "111"
}
["status"]=>
array(1) {
[0]=>
string(3) "new"
}
}
}
I'm trying to set a variable to that "1.2". Shouldn't I be able to
get it with $var = $arr[0][0]?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
$keys = array_keys($var);
var_dump($keys[0]);
string(3) "1.2"
$values = array_values($var);
var_dump($values[0]);
array(2) {
["code"]=>
array(1) {
[0]=>
string(3) "111"
}
["status"]=>
array(1) {
[0]=>
string(3) "new"
}
}
--- End Message ---
--- Begin Message ---
Hi all,
I'm getting these errors:
[04-Dec-2006 18:21:56] PHP Warning: Unknown: The session id contains
illegal characters, valid characters are a-z, A-Z, 0-9 and '-,' in Unknown
on line 0
[04-Dec-2006 18:21:56] PHP Warning: Unknown: Failed to write session data
(files). Please verify that the current setting of session.save_path is
correct (/var/lib/php5) in Unknown on line 0
[04-Dec-2006 18:22:09] PHP Warning: session_start() [<a
href='function.session-start'>function.session-start</a>]: The session id
contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-,' in
/web/fotokritik.com/lib/main.php on line 24
[04-Dec-2006 18:22:20] PHP Warning: Unknown: The session id contains
illegal characters, valid characters are a-z, A-Z, 0-9 and '-,' in Unknown
on line 0
[04-Dec-2006 18:22:20] PHP Warning: Unknown: Failed to write session data
(files). Please verify that the current setting of session.save_path is
correct (/var/lib/php5) in Unknown on line 0
The project was running for a long time without any problems, today these
errors show up...
I installed ZendPlatform trial and uninstalled maybe related but I don't
knwo where to start.
I checked session.save_path and other options. Seems to be normal.
Do you have any ideas?
--- End Message ---
--- Begin Message ---
Is there any way for PHP to know whether it is being called due to a
browser refresh versus a mouse click? I think the answer is no but I
just want to be sure. Thanks.
--- End Message ---
