php-general Digest 31 Oct 2004 07:59:11 -0000 Issue 3084

Topics (messages 200731 through 200750):

Re: php compiler
        200731 by: Curt Zirzow

php.ini Path at Runtime
        200732 by: Chris Shiflett
        200733 by: Jonel Rienton
        200745 by: Chris

Re: Using Google's API with PHP
        200734 by: Chris Martin

Re: PHP in CGI ....php.in
        200735 by: Jonel Rienton

Re: php.ini Path at Startup
        200736 by: Chris Shiflett
        200739 by: Marek Kilimajer
        200744 by: Jonel Rienton

Re: image files - upload and managment
        200737 by: Matthew Weier O'Phinney
        200740 by: Robby Russell
        200743 by: Jason Wong
        200750 by: Per Jessen

Security: Forms and displaying invalid data
        200738 by: rjc
        200741 by: Graham Cossey
        200742 by: Manuel Lemos

Re: Gawd I hate those useless error messages...
        200746 by: -{ Rene Brehmer }-

mysql_select_db error
        200747 by: Steven James Samuel Stapleton

mailparse or imap* ?
        200748 by: Per Jessen

MultiSelect List Box in PHP
        200749 by: Andy B

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 ---
* Thus wrote Hodicska Gergely:
> If you see the output, it seems, that PHP evaluate first $b = 0, and 
> this is the problem.
> 
> > $a = 1 && $b = 0
> > PHP sees two expressions here:
> 
> After the precedence table the first thing should be evaluating 1 && $b, 
> so we get:
> $a = false = 0
> Which is not meaningful thing, and maybe this cause that the evaluating 
> of the statment is not in the right order.

&& takes precedence to the left operator's expression and compares
it to the right side, you really want;

$a = 1 && $b && $b = 0


In what ever case, your expression is rather unclear on what you
want to happen.  

if( 1 && $b ) {
  $a = 1;
  $b = 0;
)


Curt
-- 
Quoth the Raven, "Nevermore."

--- End Message ---
--- Begin Message ---
Does anyone know whether there is a way to specify the path of php.ini
within httpd.conf or something similar? There is an environment variabled
named PHPRC that is almost useful enough, but it must exist within the
environment used to start Apache (e.g., using SetEnv in httpd.conf won't
work - the description of putenv() sounds much the same).

I am basically looking for an elegant method of specifying the path to the
php.ini to use when starting Apache, much like how I can specify the path
to httpd.conf with the -f flag:

/usr/local/apache/bin/httpd -f /path/to/httpd.conf

Thanks.

Chris

--- End Message ---
--- Begin Message ---
There was a very recent discussion about this, look up the archive from
the past week or 2.

regards,
Jonel

> Does anyone know whether there is a way to specify the path of php.ini
> within httpd.conf or something similar? There is an environment
> variabled named PHPRC that is almost useful enough, but it must exist
> within the environment used to start Apache (e.g., using SetEnv in
> httpd.conf won't work - the description of putenv() sounds much the
> same).
>
> I am basically looking for an elegant method of specifying the path to
> the php.ini to use when starting Apache, much like how I can specify the
> path to httpd.conf with the -f flag:
>
> /usr/local/apache/bin/httpd -f /path/to/httpd.conf
>
> Thanks.
>
> Chris
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php


-- 

--- End Message ---
--- Begin Message --- Err, I'm not sure how useful this info would be, you may know this already, but that wasn't evident in your post.

The Apache 2 php module has a PHPIniDir directive. If you're using 1.3 it may be possible to compile that feature into it with a minimum of fuss, though I wouldn't even have a clue about that.

Chris

Chris Shiflett wrote:

Does anyone know whether there is a way to specify the path of php.ini
within httpd.conf or something similar? There is an environment variabled
named PHPRC that is almost useful enough, but it must exist within the
environment used to start Apache (e.g., using SetEnv in httpd.conf won't
work - the description of putenv() sounds much the same).

I am basically looking for an elegant method of specifying the path to the
php.ini to use when starting Apache, much like how I can specify the path
to httpd.conf with the -f flag:

/usr/local/apache/bin/httpd -f /path/to/httpd.conf

Thanks.

Chris




--- End Message ---
--- Begin Message --- Rahul S. Johari wrote:
Ave,

Has anyone been able to successfully use the Google API with PHP here? I've
been trying different scripts and each one gives me a similar "Unexpected
T_Function" error.

The other script from digitalpoint.com does run but it doesn't read my $q,
basically it displays all results from google.. It doesn't actually read my
query at all.

Any help would be appreciated.

Ave.


Rahul S. Johari Coordinator, Internet & Administration Informed Marketing Services Inc.

(518) 266-0909 x154
http://www.informed-sources.com


I've done this using the NuSOAP class.

http://www.chriscodes.com/google/

I have a simple source code example. You'll need to include NuSOAP, and to replace "Your Google License KEY" in the example with Your Google License KEY.

http://www.chriscodes.com/google/google.phps

There's a somple tutorial at:
http://www.devshed.com/c/a/PHP/Using-The-Google-Web-APIs-With-PHP/

--
Chris Martin
Web Developer
Open Source & Web Standards Advocate
http://www.chriscodes.com/

--- End Message ---
--- Begin Message ---
Hi,

where did you place your php.ini?

regards,
Jonel

--
I not know English well, but I know 7 computer languages.


On Oct 30, 2004, at 2:48 AM, Christian Ista wrote:


#!/usr/bin/php -c /path/to/php.ini

I tried this

#!/usr/local/lib/php -c php.ini

In the php.ini :
register_globals = on

but that's not work

Any idea ?

Christian,

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


--- End Message ---
--- Begin Message ---
--- Jonel Rienton <[EMAIL PROTECTED]> wrote:
> There was a very recent discussion about this, look up the
> archive from the past week or 2.

If you're referring to the responses to this question:

http://marc.theaimsgroup.com/?l=php-general&m=109907804615206&w=2

then it's a different issue. If you're not, maybe you can elaborate. I've
been active on this list for years, and I don't recall seeing the answer
to this question. :-)

I'm thinking it's because there isn't a way, and if this is the case, I
want to add it (or convince someone smarter than me to add it).

Just to clarify the question, I want to be able to start Apache and
specify which php.ini I want PHP to use, much like how I can with
httpd.conf:

/usr/local/apache/bin/httpd -f /path/to/httpd.conf

Chris

--- End Message ---
--- Begin Message --- Chris Shiflett wrote:
--- Jonel Rienton <[EMAIL PROTECTED]> wrote:

There was a very recent discussion about this, look up the
archive from the past week or 2.


If you're referring to the responses to this question:

http://marc.theaimsgroup.com/?l=php-general&m=109907804615206&w=2

then it's a different issue. If you're not, maybe you can elaborate. I've
been active on this list for years, and I don't recall seeing the answer
to this question. :-)

I'm thinking it's because there isn't a way, and if this is the case, I
want to add it (or convince someone smarter than me to add it).

Just to clarify the question, I want to be able to start Apache and
specify which php.ini I want PHP to use, much like how I can with
httpd.conf:

/usr/local/apache/bin/httpd -f /path/to/httpd.conf

Chris


I think this should work:

PHPRC=/etc/php-2.ini /usr/local/apache/bin/httpd -f /path/to/httpd.conf
--- End Message ---
--- Begin Message --- I misread your question, thought you were referring to the same discussion about the php as cgi :-)

regards,
Jonel

--
I not know English well, but I know 7 computer languages.


On Oct 30, 2004, at 4:05 PM, Chris Shiflett wrote:

--- Jonel Rienton <[EMAIL PROTECTED]> wrote:
There was a very recent discussion about this, look up the
archive from the past week or 2.

If you're referring to the responses to this question:

http://marc.theaimsgroup.com/?l=php-general&m=109907804615206&w=2

then it's a different issue. If you're not, maybe you can elaborate. I've
been active on this list for years, and I don't recall seeing the answer
to this question. :-)

I'm thinking it's because there isn't a way, and if this is the case, I
want to add it (or convince someone smarter than me to add it).

Just to clarify the question, I want to be able to start Apache and
specify which php.ini I want PHP to use, much like how I can with
httpd.conf:

/usr/local/apache/bin/httpd -f /path/to/httpd.conf

Chris


--- End Message ---
--- Begin Message ---
* Robby Russell <[EMAIL PROTECTED]>:
> On Sat, 2004-10-30 at 02:43 -0700, Jaskirat Singh wrote:
> > App needs to allow users to upload pictures. (jpg and gif),
> > needs to create thumbnails of those pictures
> > and to store thumbnails and full pictures.
> > 
> > App needs to manage all those files - can be as much as 20K plus
> > images.
> > 
> > I think image file size, file type and image dimensions restrictions
> > should be easy to handle by using $_FILES array and  getimagesize
> > function.
> > 
> > The issues that I am thinking of and need suggestions about are
> > 
> > 1) Storage and retrieval -  File system sounds like a better choice
> > over database. We are talking about 20 thousand plus pictures.
>
> I would do it in the database (PostgreSQL in my case). The speed isn't
> going to be much slower if you keep things optimized. You can even cache
> your images if necessary on the filesystem (for high traffic images).

I have difficulty believing retrieving an image from a database will
have similar speed performance as simply grabbing it from the
filesystem... and if you're seeing a need to cache images on the
filesystem anyways, that's certainly already an argument against it.

> > 2) Thumbnails - Should I create those once and save it in a file when
> > the image is uploaded for the first time. Looks like a faster option
> > than creating them every time on the fly.
>
> I just recently finished working on a project where I knew that would
> automatically create a thumbnail version of each image on upload... but
> then I realized that I might one day want to change the default
> thumbnail sizes.. so what I did was have it create a thumbnail on the
> fly from the database. (this way I can control the thumbnail size in the
> future). The speed difference was hardly noticed. I have done what I
> mentioned above and am now caching images that get loaded frequently. 

Thumbnailing on the fly may have decent performance, but it *is* slower
than simply serving up an image. If you doubt that, try surfing from a
T1 connection some time (dial-up users may not notice the extra time
required to generate the image, but those on broadband will). In
addition, if you generate a thumbnail every time the image is requested,
you're making your server do extra work -- even if you're caching
oft-requested images.

I understand the argument regarding a future change in thumbnail sizes.
However, generating thumbnails on a filesystem of images is something
that is easily scripted and can be performed on an as-needed basis.
(ImageMagick is great for this sort of thing, and scripts in PHP using
GD could also be used.)

> > 3) Security issues - I believe I must have a world writable "666"
> > permissions directory to keep images as users of the web app are
> > uploading them. Does that create any security holes in my application?

Depends on if you're on your own server or a shared host. One thing you
can do even on a shared host is to make one directory 777 and then have
PHP create directories within that; however, as noted by somebody else
previously, someone else on the shared host could be malicious then and
write over those directories.

If you're on your own server or a dedicated host, give read and write
permissions only to the web server and one or two groups.

> The database will help you add a nice layer of security.

If the OP is on a shared host, that is one of the rare instances I'd
suggest putting uploaded information into a database -- and only if
there's a liklihood of other clients on the server being malicious.
However, in a shared host environment, if a user *does* do something
malicious, you can usually complain to the service provider and get
compensation.


-- 
Matthew Weier O'Phinney           | mailto:[EMAIL PROTECTED]
Webmaster and IT Specialist       | http://www.garden.org
National Gardening Association    | http://www.kidsgardening.com
802-863-5251 x156                 | http://nationalgardenmonth.org

--- End Message ---
--- Begin Message ---
On Sat, 2004-10-30 at 22:30 +0000, Matthew Weier O'Phinney wrote:
> * Robby Russell <[EMAIL PROTECTED]>:
> > On Sat, 2004-10-30 at 02:43 -0700, Jaskirat Singh wrote:
> > > App needs to allow users to upload pictures. (jpg and gif),
> > > needs to create thumbnails of those pictures
> > > and to store thumbnails and full pictures.
> > > 
> > > App needs to manage all those files - can be as much as 20K plus
> > > images.
> > > 
> > > I think image file size, file type and image dimensions restrictions
> > > should be easy to handle by using $_FILES array and  getimagesize
> > > function.
> > > 
> > > The issues that I am thinking of and need suggestions about are
> > > 
> > > 1) Storage and retrieval -  File system sounds like a better choice
> > > over database. We are talking about 20 thousand plus pictures.
> >
> > I would do it in the database (PostgreSQL in my case). The speed isn't
> > going to be much slower if you keep things optimized. You can even cache
> > your images if necessary on the filesystem (for high traffic images).
> 
> I have difficulty believing retrieving an image from a database will
> have similar speed performance as simply grabbing it from the
> filesystem... and if you're seeing a need to cache images on the
> filesystem anyways, that's certainly already an argument against it.
> 

I tend to stick as much in the database with strict restraints. I know
that in my database, an image cannot be deleted unless several rules are
met. In the filesystem, a number of things could accidently delete the
wrong file. I treat my images as another piece of data and that data is
kept there by constraints.  

> > > 2) Thumbnails - Should I create those once and save it in a file when
> > > the image is uploaded for the first time. Looks like a faster option
> > > than creating them every time on the fly.
> >
> > I just recently finished working on a project where I knew that would
> > automatically create a thumbnail version of each image on upload... but
> > then I realized that I might one day want to change the default
> > thumbnail sizes.. so what I did was have it create a thumbnail on the
> > fly from the database. (this way I can control the thumbnail size in the
> > future). The speed difference was hardly noticed. I have done what I
> > mentioned above and am now caching images that get loaded frequently. 
> 
> Thumbnailing on the fly may have decent performance, but it *is* slower
> than simply serving up an image. If you doubt that, try surfing from a
> T1 connection some time (dial-up users may not notice the extra time
> required to generate the image, but those on broadband will). In
> addition, if you generate a thumbnail every time the image is requested,
> you're making your server do extra work -- even if you're caching
> oft-requested images.
> 
> I understand the argument regarding a future change in thumbnail sizes.
> However, generating thumbnails on a filesystem of images is something
> that is easily scripted and can be performed on an as-needed basis.
> (ImageMagick is great for this sort of thing, and scripts in PHP using
> GD could also be used.)
> 

As I can do when I want it to be a thumbnail. Infact, in PostgreSQL, I
can use plPHP, plPerl, psycopg, etc and perform these tasks within
database functions. This isn't an issue at all. 

Here are a few reasons why storing in the DB can be more useful. 

http://www.oracle.com/technology/products/intermedia/htdocs/why_images_in_database.html

Also, Gallery 2, is moving to a database backend, one would wonder why
that would be a good move, considering the sole purpose of gallery is to
display images. 

-Robby

-- 
/***************************************
* Robby Russell | Owner.Developer.Geek
* PLANET ARGON  | www.planetargon.com
* Portland, OR  | [EMAIL PROTECTED]
* 503.351.4730  | blog.planetargon.com
* PHP/PostgreSQL Hosting & Development
*    --- Now supporting PHP5 ---
****************************************/

Attachment: signature.asc
Description: This is a digitally signed message part


--- End Message ---
--- Begin Message ---
On Saturday 30 October 2004 23:06, Robby Russell wrote:

> > I understand the argument regarding a future change in thumbnail sizes.
> > However, generating thumbnails on a filesystem of images is something
> > that is easily scripted and can be performed on an as-needed basis.
> > (ImageMagick is great for this sort of thing, and scripts in PHP using
> > GD could also be used.)
>
> As I can do when I want it to be a thumbnail. Infact, in PostgreSQL, I
> can use plPHP, plPerl, psycopg, etc and perform these tasks within
> database functions. This isn't an issue at all.

So the point (still) is why generate each request on the fly?

> Also, Gallery 2, is moving to a database backend, one would wonder why
> that would be a good move, considering the sole purpose of gallery is to
> display images.

Moving to a database backend is a good move on the part of Gallery because the 
current version uses flat files to store its data. However are you certain 
that the database backend is also used to store the pictures themselves? 
AFAICT this is not the case and pictures are still stored in the file system.

-- 
Jason Wong -> Gremlins Associates -> www.gremlins.biz
Open Source Software Systems Integrators
* Web Design & Hosting * Internet & Intranet Applications Development *
------------------------------------------
Search the list archives before you post
http://marc.theaimsgroup.com/?l=php-general
------------------------------------------
/*
 Earth Army Recruiting Center: What are you, chicken? Buk buk buk! 
*/

--- End Message ---
--- Begin Message ---
Robby Russell wrote:

> I tend to stick as much in the database with strict restraints. I know
> that in my database, an image cannot be deleted unless several rules are
> met. In the filesystem, a number of things could accidently delete the
> wrong file. I treat my images as another piece of data and that data is
> kept there by constraints.

If you don't feel you can protect your filesystem from accidental deletions, are
the images *really* any safer stored in a database which obviously will use the
filesystem as storage?  


/Per

-- 
Per Jessen, Zurich
Let your spam stop here -- http://www.spamchek.com

--- End Message ---
--- Begin Message --- I have a form, that takes user input, and was wondering what are your thoughts of redisplaying user input back on the page after validation has failed.

Eg. they have to enter a date in format: 'yyyy-mm-dd'
and they enter: <script>.....</script> etc. or anything for that matter.
Although that would prob be too long for the field, but you get the idea.

How do other people out there tend to handle this? As it only affects the user that post the data if anything is malicious.

Some options that I have come up with are:
1. Displaying previous data (or empty field) for example if user is editing something.
2. Just displaying exactly what they entered again on the screen.
3. Stripping out certain undesirable characters before displaying.

Thanks,

Rob
--- End Message ---
--- Begin Message ---
> -----Original Message-----
> From: rjc [mailto:[EMAIL PROTECTED]
> Sent: 30 October 2004 23:35
> To: [EMAIL PROTECTED]
> Subject: [PHP] Security: Forms and displaying invalid data
>
>
> I have a form, that takes user input, and was wondering what are your
> thoughts of redisplaying user input back on the page after validation
> has failed.
>
[snip]
>
> Some options that I have come up with are:
> 1. Displaying previous data (or empty field) for example if user is
> editing something.
> 2. Just displaying exactly what they entered again on the screen.
> 3. Stripping out certain undesirable characters before displaying.

Personally I get really p****d off when a form errors and does not return
any of my original entries, especially the larger ones. However, I
understand not re-displaying any 'sensitive' entries such as passwords,
security phrases etc. as they can aid the 'hackers'.

I would not strip out anything you won't accept as you could be giving clues
to the unscrupulous users as to what you will and won't accept.

Graham

--- End Message ---
--- Begin Message ---
Hello,

On 10/30/2004 07:35 PM, Rjc wrote:
I have a form, that takes user input, and was wondering what are your thoughts of redisplaying user input back on the page after validation has failed.

Eg. they have to enter a date in format: 'yyyy-mm-dd'
and they enter: <script>.....</script> etc. or anything for that matter.
Although that would prob be too long for the field, but you get the idea.

How do other people out there tend to handle this? As it only affects the user that post the data if anything is malicious.

Some options that I have come up with are:
1. Displaying previous data (or empty field) for example if user is editing something.
2. Just displaying exactly what they entered again on the screen.
3. Stripping out certain undesirable characters before displaying.

I think you should always display exactly what the user entered but also never avoid doing server side validation before accepting a form with invalid values.

The only situation that I recommend discarding invalid values is when you pass context values (like for instance the id of a database field being edited) through an hidden field. If the field was hidden, it would not make much sense to tell the user that the value in the hidden field is invalid. An attacker already knows that the spoofed value is not valid. There is no point in bringing that up.

Anyway, if you expect a date, always use common methods like regular expressions to validate the accepted formats.

You may want to take a look at this forms generation and validation class that comes with several examples of how to validate all sorts of fields types and only accept the form until all that is submittted is valid.

It even comes with a plug-in that implements a custom date field made of several real fields that validates dates for you, including delimiting time ranges.

http://www.phpclasses.org/formsgeneration


--

Regards,
Manuel Lemos

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/

PHP Reviews - Reviews of PHP books and other products
http://www.phpclasses.org/reviews/

Metastorage - Data object relational mapping layer generator
http://www.meta-language.net/metastorage.html

--- End Message ---
--- Begin Message --- At 15:56 29-10-2004, Richard Davey wrote:
Hello -{,

Friday, October 29, 2004, 3:28:39 PM, you wrote:

RB> since this is the test-server, I run with all errors, alerts, and messages
RB> on, but isn't there someway to make PHP just a little more helpful when
RB> this happens ???

Use an IDE that high-lights typos like this for you? Before it even
gets are far as PHP debugging it? Zend Studio for example would do
this (it did it to me several times this morning!)

Thanks ... will look into it :)

Rene

--
Rene Brehmer
aka Metalbunny

If your life was a dream, would you wake up from a nightmare, dripping of sweat, hoping it was over? Or would you wake up happy and pleased, ready to take on the day with a smile?

http://metalbunny.net/
References, tools, and other useful stuff...
Check out the new Metalbunny forums at http://forums.metalbunny.net/

--- End Message ---
--- Begin Message ---
Relevant information:
Windows XP Pro SP2
PHP 5.0.2
MySQL 4.0.21-nt
command line (not server-side)

mysql_select_db returns no errors, and does not result in a mysql_error(), however, later queries result in errors suggesting that the switch failed:



//I'm having problems with mysql_select_db("DBNAME", resource) and
$test = mysql_query("use DBNAME", $resource);

//This results in no errors (I checked to make sure a true value was returned,
//and made sure mysql_errno() returned 0).
if(!$test || mysql_errno())
{
die("Error selecting DB");
}

//next, I'll make a query:
mysql_query("create table foo ( bar int, morebar int )", $resource);
if(mysql_errno())
{
 die(mysql_error());
}
//I get
//No Database Selected



There appear to be quite a few related/similar posts, but I can't find any that address this particular variant of the problem, which are solved.

Thanks
-Jim Stapleton
--- End Message ---
--- Begin Message ---
I need functions to parse an email and I've been using mailparse sofar.  Works
pretty well, except it has a couple of shortcomings - will only retrieve last
of the Received:-headers, does not decode quoted-printable body-parts, does not
decode RFC2047-encoded filenames in COntent-Disposition. 
So I've been having a closer at imap* - but it's just not very clear if imap*
will for instance deal with a single email available as a string?

mailparse does exactly what I need, except the shortcomings listed are becoming
a problem.

any suggestions? (other than fixing mailparse :-)


-- 
Per Jessen, Zurich
Let your spam stop here -- http://www.spamchek.com

--- End Message ---
--- Begin Message ---
Hi.

I was just wondering where I can find info on how to use a MultiSelect List
Box with PHP? I need to use it with MYSQL 5.0.0, PHP 4.3.9, and windows XP
sp2.

Any help/leads would be greatly appreciated.

--- End Message ---

Reply via email to