php-general Digest 20 May 2006 22:07:30 -0000 Issue 4139
Topics (messages 236550 through 236558):
Re: open_basedir
236550 by: David Robley
Re: safe_mode
236551 by: tedd
236552 by: Rabin Vincent
236555 by: tedd
Re: Encryption Advice
236553 by: Lawrence Kennon
236554 by: Kevin Davies
Re: Running two versions of PHP locally
236556 by: Koen Martens
Re: round behavior changed
236557 by: tedd
Captcha v1.0 (http://www.php.meezerk.com/index.php?page=captcha)
236558 by: Beauford
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:
php-general@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
Nanu Kalmanovitz wrote:
> Hi!
>
> Using Apache 2, MySQL ver. 4.0.15a, PHP 4.2.3 (NW6.5 sp1 - Netware \
> Novell ).
>
> I'm developing PHP files with Dreamweaver8 (Adobe-Macromedia).
>
> Trying to view a file (quote_insert.php) in a browser, it displays at:
>
>
> http://www.kalmanovitz.co.il/DW8_PHP_MySQL_tutorial/admin/quote_insert.php
>
>
> the following warning \ error:
>
> Warning: open_basedir restriction in effect. File is in wrong directory
> in Applic:/HTDocs/DW8_PHP/admin/quote_insert.php on line 1
>
> Fatal error: Failed opening required '../Connections/seasonAdmin.php'
> (include_path='.;sys:/php/includes') in
> Applic:/HTDocs/DW8_PHP/admin/quote_insert.php on line 1
>
> while line 1 is:
>
> <?php require_once('../Connections/seasonAdmin.php'); ?>
>
>
> If I'm changing the line 1 to:
>
> <?php require_once('Connections/seasonAdmin.php'); ?>
>
> without the ../ characters and copy the quote_insert.php file to
> DW8_PHP folder it works OK.
>
> How can I solved the problem without removing the ../ and moving the
> file?
> I changed the PHP file to begin with the following code (added paths
> to every directory \ folder that is involved):.
>
> Now the PHP file to begin with the following code:
>
> <?php
> echo nl2br("Original include path:\n");
> echo ini_get('include_path').nl2br("\n\n");
>
ini_set('include_path',ini_get('include_path').';Applic:/HTDocs/DW8_PHP/admin;Applic:/HTDocs/DW8_PHP/Connections;Applic:/HTDocs/DW8_PHP/');
>
> echo nl2br("New include path:\n");
> echo ini_get('include_path').nl2br("\n");
>
> require_once('Applic:/HTDocs/DW8_PHP/Connections/seasonAdmin.php');
> ?>
>
> You can see the display at
> http://www.kalmanovitz.co.il/DW8_PHP/admin/quote_insert.php
>
> The displayed warning \ error message says:
> Original include path:
> .;sys:/php/includes
>
> New include path:
> .;sys:/php/includes;Applic:/HTDocs/DW8_PHP/admin;Applic:/HTDocs/DW8_PHP/Connections;Applic:/HTDocs/DW8_PHP/
>
>
> Warning: open_basedir restriction in effect. File is in wrong directory
> in Applic:/HTDocs/DW8_PHP/admin/quote_insert.php on line 8
>
> Fatal error: Failed opening required
> 'Applic:/HTDocs/DW8_PHP/Connections/seasonAdmin.php'
>
(include_path='.;sys:/php/includes;Applic:/HTDocs/DW8_PHP/admin;Applic:/HTDocs/DW8_PHP/Connections;Applic:/HTDocs/DW8_PHP/')
> in Applic:/HTDocs/DW8_PHP/admin/quote_insert.php on line 8
>
>
> Can anyone see \ find what is wrong?
You apparrently have a setting activated in your php.ini that restricts
opening files to a certain directory structure. Go to
http://il.php.net/manual/en/features.safe-mode.php and scroll down til you
get to the section on open_basedir which will tel you what the setting is
about. You can change it in php.ini for global effect, or in httpd.conf for
specific locations
Cheers
--
David Robley
I used to have a handle on life, then it broke.
Today is Setting Orange, the 67th day of Discord in the YOLD 3172.
--- End Message ---
--- Begin Message ---
At 9:01 PM -0400 5/19/06, John Hicks wrote:
tedd wrote:
Hi gang:
Please excuse me for asking another dumb-ass question, but here goes.
I'm finding that setting safe_mode to ON is more difficult than I
first thought.
In my phpinfo, safe_mode is set to OFF
-snip-
You would think the fine manual would explain this here:
http://us3.php.net/manual/en/features.safe-mode.php
Table 42-1. Security and Safe Mode Configuration Directives
Name: safe_mode
Default: "0"
Changeable: PHP_INI_SYSTEM
but you have to look here
http://us3.php.net/manual/en/ini.php
to find just what PHP_INI_SYSTEM means:
Table G-2. Definition of PHP_INI_* constants
Constant: PHP_INI_SYSTEM
Value: 4
Meaning: Entry can be set in php.ini or httpd.conf
i.e. *not* in .htaccess or by ini_set()
[ Boy, do I dread posting this. ]
Okay, safe_mode cannot be set by .htaccess or by ini_set(). It can
only be set by the php.ini file -- I get it -- thanks.
So, now I'm trying to get my own php.ini file to work.
I reviewed several links, but the easiest I found to understand was:
http://www.washington.edu/computing/web/publishing/php-ini.html
I didn't see any references that disagreed.
So, as I understand it, one procedure to get a custom php.ini file to work is:
1. Get a php.ini templet.
2. Alter as you like.
3. Place it in your working directory.
I did that, and the results can be viewed at:
http://xn--ovg.com/aaa
However, regardless of what my php.ini file states, the directives I
changed remain unchanged.
What other obvious thing am I not seeing?
Thanks.
tedd
--
------------------------------------------------------------------------------------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
On 5/20/06, tedd <[EMAIL PROTECTED]> wrote:
At 9:01 PM -0400 5/19/06, John Hicks wrote:
>tedd wrote:
>>Hi gang:
>>
>>Please excuse me for asking another dumb-ass question, but here goes.
>>
>>I'm finding that setting safe_mode to ON is more difficult than I
>>first thought.
>>
>>In my phpinfo, safe_mode is set to OFF
>>
>-snip-
>
>You would think the fine manual would explain this here:
>http://us3.php.net/manual/en/features.safe-mode.php
>
>Table 42-1. Security and Safe Mode Configuration Directives
>Name: safe_mode
>Default: "0"
>Changeable: PHP_INI_SYSTEM
>
>but you have to look here
>http://us3.php.net/manual/en/ini.php
>to find just what PHP_INI_SYSTEM means:
>
>Table G-2. Definition of PHP_INI_* constants
>Constant: PHP_INI_SYSTEM
>Value: 4
>Meaning: Entry can be set in php.ini or httpd.conf
>
>i.e. *not* in .htaccess or by ini_set()
[ Boy, do I dread posting this. ]
Okay, safe_mode cannot be set by .htaccess or by ini_set(). It can
only be set by the php.ini file -- I get it -- thanks.
So, now I'm trying to get my own php.ini file to work.
I reviewed several links, but the easiest I found to understand was:
http://www.washington.edu/computing/web/publishing/php-ini.html
I didn't see any references that disagreed.
So, as I understand it, one procedure to get a custom php.ini file to work is:
1. Get a php.ini templet.
2. Alter as you like.
3. Place it in your working directory.
I did that, and the results can be viewed at:
http://xn--ovg.com/aaa
However, regardless of what my php.ini file states, the directives I
changed remain unchanged.
What other obvious thing am I not seeing?
php.net/ini says that php.ini in the working directory is only
used if PHP is run from the command line.
For PHP running on the web server, you should edit the
system's php.ini file. You can find the location of this file
with phpinfo(). Look for "Configuration File (php.ini) Path".
Rabin
--- End Message ---
--- Begin Message ---
What other obvious thing am I not seeing?
php.net/ini says that php.ini in the working directory is only
used if PHP is run from the command line.
For PHP running on the web server, you should edit the
system's php.ini file. You can find the location of this file
with phpinfo(). Look for "Configuration File (php.ini) Path".
Rabin
Rabin:
Okay, I can find and read the file, but editing is a bit too scary
for me at the moment. It's one thing to edit it in a local directory
-- it's another to edit it deep within the system. Besides, I'm not
sure that I can anyway.
Many thanks.
tedd
--
------------------------------------------------------------------------------------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
--- Rory Browne <[EMAIL PROTECTED]> wrote:
> It's better if, when it comes to time
> to checkout, you redirect your client
> to your Payment Service Providers (PSP's)
> website, your PSP processes the payment,
> and redirects the client back to your
> site. The PSP would then contact you
> directly to confirm the payment.
> That way there is no CC info on your
> server for you to protect.
I really appreciate all the advice people have given.
So the following questions are designed to try to
fully understand the scenario and what the customer
sees from their viewpoint.
The site that I am trying to fix is absolutely awful
right now. It is certainly not a high volume site,
although I do think if properly designed it could do a
lot more business than it does. It is the site of a
self-published author and I think most people who buy
his books go to Amazon to buy them because the
shopping cart is so bad (he did it himself years ago,
and he is not any kind of web designer or programmer).
The site uses the Hassan Shopping Cart which is a Perl
script. Looking at the script it appears that it can
support some sort of credit card authorization. But
the way he has it set up now it just writes each order
to a plain text file in a "secure" subdirectory
(obviously a very bad idea) and sends him an email
that tells him he has an order on the site to process.
His hosting site is discontinuing support for the
Hassan Shopping Cart, but does support Cardservice
International.
So let's say that I want to integrate a shopping cart
with a PSP, right up to the moment they get to the
checkout, they see my client's URL. They hit the
"Checkout" button and then they will see the URL of
the PSP? Then once they place the order then they are
redirected back to my client's site and see that URL
again? Is that an accurate description of how it
works? Do you normally have control over the "look and
feel" of how the checkout looks on the PSP site?
Excuse me if these are really basic questions, but I
haven't done this before. :)
Thanks again,
Lawrence Kennon
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--- End Message ---
--- Begin Message ---
<snip>
So let's say that I want to integrate a shopping cart
with a PSP, right up to the moment they get to the
checkout, they see my client's URL. They hit the
"Checkout" button and then they will see the URL of
the PSP? Then once they place the order then they are
redirected back to my client's site and see that URL
again? Is that an accurate description of how it
works? Do you normally have control over the "look and
feel" of how the checkout looks on the PSP site?
</snip>
Hi Lawrence,
The way you explain it is the way that most of the Payment Service providers
seem to work.
However - depending on the PSP you use will depend on how much of the look
and feel you can change. PayPal for example only allows very basic styling,
whereas something like WorldPay (not sure if they are UK only) allows you to
create templates, so other than the URL the change is seamless.
The PSP will send you an email with the order details, and additionally most
can post back to a script on your server with the details of the transaction
- i.e. did it work? What was the total amount/currency? Etc.
You can then use this to validate it's the correct transaction and send your
own email/receipt/picking list accordingly.
I've worked on a couple of these so if I can be of any help give me a shout.
Cheers,
Kev
--- End Message ---
--- Begin Message ---
Scott Hurring wrote:
> On 5/19/06, John Hicks <[EMAIL PROTECTED]> wrote:
[snip]
>> It looks like 'application/x-httpd-php' is the default type for php4.
>> Does php5 have a different type? Is there a way to explicitly assign a
>> new type to a module?
[snip]
> I'd be interested to know if anyone does get both php4 & php5 modules
> installed together without file extention hints or port proxying.
[snip]
I took a quick look, and just changing the type to x-httpd-php5 for
example (by editting the source) is not enough. The two modules are
in eachothers way, there are double free's and segfaults that are
not easy to find when you load both modules in one apache (at least,
not for someone who is not an apache/php source code expert).
Gr,
Koen
--
K.F.J. Martens, Sonologic, http://www.sonologic.nl/
Networking, hosting, embedded systems, unix, artificial intelligence.
Public PGP key: http://www.metro.cx/pubkey-gmc.asc
Wondering about the funny attachment your mail program
can't read? Visit http://www.openpgp.org/
--- End Message ---
--- Begin Message ---
At 3:17 PM -0500 5/19/06, Richard Lynch wrote:
On Fri, May 19, 2006 1:27 pm, Sébastien Guay wrote:
I searched the archives but did not found anything.
It seem that the round function behavior has changed in php 4.4.x (I
don't
have 4.4.1 handy for testing).
In 4.3.11, the output of round("23.005",2) is 23.01 which is
mathematically
correct.
In 4.4.2, the output is 23 which is not correct. The output of
round("23.0051",2) is correct though (23.01).
Is there a workaround/patch for this?
The correctness of rounding kinda depends on which
mathematical/historical model one subscribes to.
There is at least one statistician's model of 'round' wherein a
trailing '5' goes 'up' for preceding even numbers and 'down' for
preceding odd numbers, to provide more symmetry in statistical
analysis of rounding.
Or, at least, that's how I recall it.
Your recall is correct.
The reasoning is that for a trailing 1-4, you
round down; for 6-9, you round up; and for 0 you
don't do anything, but for five it becomes a
statistical problem as to which way you round.
If you always round up, then the bias is up. If
you always round down (which I believe php does),
then the bias is down.
However, if you use the statistician's model (up
for even and down for odd whole numbers), then
rounding errors are reduced as compared to other
methods, but they are not eliminated.
tedd
--
------------------------------------------------------------------------------------
http://sperling.com http://ancientstones.com http://earthstones.com
--- End Message ---
--- Begin Message ---
Hi,
I am trying to get a program, Captcha v1.0, working and not having much
luck. The program says I need PHP version 4.3.10 or later or PHP version 5
and GD Library version 2.0 or later with JPEG support.
I know I have PHP 5, but not sure about the GD Library. I was reading on one
page I was on that this is built in to PHP, but at this point I'm lost. When
I try to compile the latest version on my Slackware box I get nothing but
errors.
Any help would be appreciated.
Thanks
B
--- End Message ---
