php-general Digest 5 Aug 2006 18:25:34 -0000 Issue 4276
php-general Digest 5 Aug 2006 18:25:34 - Issue 4276
Topics (messages 240180 through 240187):
PayPal's PHP SDK on Windows
240180 by: s2j1j1b0
240182 by: Peter Lauri
240183 by: Paul Scott
Re: Problem with wrapper script for Tidy
240181 by: Frank Arensmeier
Sending data to persistent process stdin
240184 by: Ville Mattila
240187 by: Stut
Re: php behind firewall
240185 by: tedd
Re: PHP Frameworks - Opinion
240186 by: Tony Marston
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 ---
I'm trying to get PayPal's PHP SDK
running on Windows. After running install.php, I get the following error:
"The PayPal SDK requires curl with SSL support"
How do I fix this?
--
View this message in context:
http://www.nabble.com/PayPal%27s-PHP-SDK-on-Windows-tf2054950.html#a5661901
Sent from the PHP - General forum at Nabble.com.
--- End Message ---
--- Begin Message ---
Hi,
Try www.php.net/curl
/Peter
-Original Message-
From: s2j1j1b0 [mailto:[EMAIL PROTECTED]
Sent: Saturday, August 05, 2006 1:51 PM
To: php-general@lists.php.net
Subject: [PHP] PayPal's PHP SDK on Windows
I'm trying to get PayPal's PHP SDK
running on Windows. After running install.php, I get the following error:
"The PayPal SDK requires curl with SSL support"
How do I fix this?
--
View this message in context:
http://www.nabble.com/PayPal%27s-PHP-SDK-on-Windows-tf2054950.html#a5661901
Sent from the PHP - General forum at Nabble.com.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
--- Begin Message ---
On Fri, 2006-08-04 at 23:50 -0700, s2j1j1b0 wrote:
> "The PayPal SDK requires curl with SSL support"
>
> How do I fix this?
You do what it says, install and configure cURL with SSL support. cURL
releases binaries for your OS at http://curl.haxx.se/ AFAIK they will
have a precompiled binary with SSL support built in. All that is left
after that is to enable curl as an extension in php.ini
;extension=curl.dll or something like that...
You just need to uncomment that line and restart your webserver.
HTH
--Paul
All Email originating from UWC is covered by disclaimer
http://www.uwc.ac.za/portal/uwc2006/content/mail_disclaimer/index.htm
--- End Message ---
--- Begin Message ---
Thank you Richard. I will test that (piping the output). Regarding my
concerns about "rubbing security" by not validating the included
code, I actually meant that the script does not validate where the
included PHP script is coming from. Could someone set the
environmental variable $_SERVER('PATH_TRANSLATED') from outside, so
to say? Or is there no reason to be worried?
/frank
4 aug 2006 kl. 22.22 skrev Richard Lynch:
Did you try to use "-" as the file and pipe the output?...
That might work...
As far as the Tidy not validating the included PHP, I'm not sure what
you mean, but I don't see this making the PHP code any less secure
than it was before you wrapped Tidy around it...
On Fri, August 4, 2006 6:21 am, Frank Arensmeier wrote:
Hello.
Since my ISP does not provide the tidy module for Apache, I tested
writing a wrapper script for a locally installed tidy binary. In
general, the script is triggered by a modification to the .htaccess
file like so:
AddHandler server-parsed .php
Action server-parsed /tidy_wrapper.php5
All php pages are by that means "treated" by the script
tidy_wrapper.php5.
Here is the code for tidy_wrapper.php5:
" will turn
off tidy conversion
if ( !stristr ( $output, "" ) ) {
$localfile = tempnam ( '../tmp', "tmp" );
$handle = fopen($localfile, "w");
fwrite($handle, $output);
fclose($handle);
$command = '/Library/WebServer/CGI-Executables/tidy -iq --show-
errors 0 --show-warnings 0 -wrap 100 ' . $localfile . ' 2>&1';
exec ( $command, $output_exec );
echo implode ( "\n", $output_exec );
unlink ( $localfile );
} else {
echo $output;
}
exit;
?>
Although the script is actually working fine, there is at least one
downside: speed. As you can see, the output buffer must be written to
a file in order to be processed by tidy. I was not able to get tidy
to accept a string for processing. Doing so, tidy throws en error. I
have looked through tidy documentation without finding any clues. I
would appreciate any hints. Any ideas for a walk-around for that file
saving-thing would be welcome!
Otherwise, I strongly feel that this script might become/be a
security hole. Because it does not validate the included PHP code, it
could be misused for doing bad stuff, or am I wrong? Once more, any
suggestions are welcome.
regards,
/frank
--
PHP General Mailing List (http
php-general Digest 6 Aug 2006 06:31:46 -0000 Issue 4277
php-general Digest 6 Aug 2006 06:31:46 - Issue 4277 Topics (messages 240188 through 240197): Re: Sending data to persistent process stdin 240188 by: Ville Mattila 240190 by: Stut Re: PHP Frameworks - Opinion 240189 by: Manuel Lemos 240193 by: Robert Cummings Re: The difference between ereg and preg? 240191 by: Dave M G 240194 by: Robert Cummings Using preg_match to find Japanese text 240192 by: Dave M G Re: PayPal's PHP SDK on Windows 240195 by: phpwizard02 #comment, (* comment *), -- Any good alternatives to 240196 by: Micky Hulse 240197 by: Micky Hulse 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 --- Stut kirjoitti: 1) Find out how to create a named pipe and start mpg123 to take its input from that named pipe. Your PHP scripts can then write commands to that pipe. Thanks Stut, rather good idea... I tried following commands: mkfifo mpg mpg123 -R < mpg And in another shell echo "LOAD mp3file.mp3\n" > mpg Unfortunately, the mpg123 quits immediately without any response... In general, the idea sounds good, but there is still something uncompatible. Ville --- End Message --- --- Begin Message --- Ville Mattila wrote: > Stut kirjoitti: >> 1) Find out how to create a named pipe and start mpg123 to take its >> input from that named pipe. Your PHP scripts can then write commands to >> that pipe. >> > > Thanks Stut, rather good idea... I tried following commands: > > mkfifo mpg > mpg123 -R < mpg > > And in another shell > echo "LOAD mp3file.mp3\n" > mpg > > Unfortunately, the mpg123 quits immediately without any response... In > general, the idea sounds good, but there is still something uncompatible. There's really no good reason that shouldn't have worked. I suggest you find an mpg123 mailing list and ask them why that happened. -Stut --- End Message --- --- Begin Message --- Hello, on 08/04/2006 05:47 PM Robert Cummings said the following: >> The point of the post is that there is no framework in particular to >> recommend. I use my own packages for my needs. They suit me well. It >> does not mean they will suit everybody. > How would you know that there is no framework to recommend if you neve > ruse anyone's code but your own. How could you have possibly given any > framework sufficient attention to have any idea of its pros and cons? I know many frameworks that exist, I have seen their code and their documentation, which is more than enough to reach the conclusion that using the frameworks that exist is not better that using my own solutions for my own purposes. >>> Aaaah, so you are trully a genius to be able to at a glance of >>> documentation and source code fully deduce the usefulness of something. >>> I bow before you. >> Be seriuos. Nobody needs to actually use any framework to see that it is >> not suitable for your needs, when you can just browse the source code >> and documentation. It would be insane to try all PHP frameworks that >> exist to reach that conclusion. > > And there's the rub... your article was not about what YOU needed it was > what YOU considered to be the best framework for everyone based on > briefly browsing the code. Your article, if it had any real merit, would > have reported on the actual trial of a substantial number of frameworks > so that you could provide a valuable analysis instead of superficial > opinion. Remember a recommendation, is not about YOU, it's about those > reading the article. I can agree with your previous statement until you > start recommending it in general. My article is mine. It was not written for you but rather to the PHPClasses site users in first place. Therefore it includes whatever I think it is best for me to mention. If you do not agree and think it should be something else, go and write your own article in your own blog rather than bossing me to do something different, as if I owe you anything. > You can't have your cake and eat it too. You're either pro-choice with a > myriad of choices to choose from, or you're anti-choice and want only > one framework style. Get of the fence! Having standard API specifications does not prevent anybody to choose using solutions based on APIs that do not conform to any standard specifications. Furthermore I do not think that seem to understand the difference between an API specification and API implementation. J2EE is an API specification with many implementations from different vendors: Sun, IBM, Oracle, BEA, JBoss (this last one is Open Source). You can choose the implementation you want. There is plenty of choice to anybody.
