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 --- ****************************************/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 ---