[PHP] Secure Access to Remote MySQL DB
Greetings, I am developing an application that will access a MySQL database remotely from another server. I would like to be able to use a standard database connection using the 3306 port if possible for ease of development, but I certainly do not want to be sending unencrypted data between my application and the database. Is there a way to encrypt the database transactions between PHP and a remote MySQL database? Matt -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP] Secure Access to Remote MySQL DB
Greetings, I have seen hints at the SSL functionality in MySQL, but I have not been able to find any documentation on how exactly I am supposed to use it. Does this require special processing on the PHP end of things to activate an SSL connection to the database? Matt -Original Message- From: Mauricio T?llez Jim?nez [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 18, 2001 12:03 PM To: Matthew Aznoe Cc: Php-General-Digest Subject: Re: [PHP] Secure Access to Remote MySQL DB CONTENT-DISPOSITION: INLINE I think that SSL is the more transparent choice. Cheers. On Wed, Jul 18, 2001 at 11:38:19AM -0600, Matthew Aznoe wrote: Greetings, I am developing an application that will access a MySQL database remotely from another server. I would like to be able to use a standard database connection using the 3306 port if possible for ease of development, but I certainly do not want to be sending unencrypted data between my application and the database. Is there a way to encrypt the database transactions between PHP and a remote MySQL database? Matt -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP] Variable name declarations?
I have to agree that strong typing is not a good fit with PHP. It really
limits the flexibility of the language that is, at least to me, one it its
strongest appeals. Often, strong typing can be overly restrictive, and free
typing, when combined with good comments and documentation which should go
alongside any piece of code, allows much easier development in my
experience.
However, I do have one complaint about PHP that seems to have a tendency to
bite me far too often, and that is the lack of variable declaration. While
I do not think the type of the variable should be required, requiring the
user to specify which variable names are going to be used I think would be
useful. The reason why I believe this is important is in debugging. I have
been caught many times misspelling a variable name slightly (ie - ei), and
since PHP does no variable name checking, sometimes it takes a while to
discover the error. If each variable name had to be declared prior to use,
it would eliminate this problem by warning the user each time an undeclared
name was used.
The syntax could be very simple using constructs that already exist in the
langauge. The name would be defined by using the var command somewhere in
code prior to the variable being used (as in classes... but here again, the
class elements are not limited to those defined). The declaration would
reserve only the name of the variable, so the actual type would continue to
be free form. Arrays could continue to be created as they are now since
only the name of the variable would be checked (you could still have
potential problems in associative arrays). Global PHP variables (ie
$GLOBALS) would not need to be declared (they would be declared
automatically).
example:
function sum_array( $input_array )
{
var $index;
var $sum = 0;
for( $index = 0; $index count( $input_array ); $index++ )
$sum += $input_array[ $index ];
return $sum;
}
Potentially, the $index variable could also be declared within the for loop
by adding a var before the first index as well. To keep things simple and
in line with the current variable scope rules, the scope of the name would
be global for the function in which it was defined.
I do not know all of the logistics behind the parsing and compilation
processes in the PHP engine, but I believe this could be done without too
much overhead. It could be an optional feature (controlled from the php.ini
file) that could be turned off when released to production to save on
performance. If this value was defaulted to off in the release, it would
also allow people to upgrade existing code to the new version without
having to worry about instantly changing their code to the new paradigm.
I do not believe that this would sacrifice very much freedom in the
language, and it would certainly make debugging and maintainence easier on
the developer. Also, by having all of the variables declared at the top of
the functions, it could help commenting by describing the variable name as
it is being declared, and it would encourage a better coding style.
Does anyone else have any thoughts on this?
Matthew Aznoe
[EMAIL PROTECTED]
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP] preg vs ereg (performance)
I am in the process of writing an application that does a lot of parsing in
which performance is the key. In the process, I performed some rudimentary
speed testing that yielded some interesting results. Rather than keep them
to myself, I thought I would share them.
I am currently parsing out the contents of general webpages, so for the test
case, I used a string that contained the html to generate a fairly standard
select list (with 31 options). For the first test, I merely wanted to pull
out the name of the select element. I used the following two parsing
commands in a side-by-side timing comparison and ran each in a loop 5000
times to get a larger time value:
preg_match(
/name=[ ]?(['\])?((?(1)[^\\1]|[^\s\])+?)(?(1)\\1|[\s])/i, $string,
$arr );
eregi( name=[\']{0,1}([_0-9a-zA-Z]+)[\']{0,1}, $string, $arr );
Note: The preg_match expression is actually far more accurate that the eregi
as well as complex. It handles the case of name=34 multiple as well as
name='my select'. Both expressions were also case insensitive.
The results:
preg_match
Timer: This page was generated in 0.26572799682617 seconds.
eregi
Timer: This page was generated in 1.2171900272369 seconds.
The preg_match is considerably faster than ereg and much more powerful (the
PHP homepage for the documentation), and while the syntax takes a little
adjustment (if you have never used Perl before), it is not that difficult to
convert to. When I replaced all of my eregi statements with their
preg_match equivalents, I found that the parsing portion of my page went
from .46 seconds to .23. When it comes to regular expression pattern
matching, I have come to the conclusion that the only option is preg_match.
Inspired by this revelation, I decided to test preg_split vs split vs
explode. It was not nearly as interesting, but I thought I would post my
results nonetheless.
Using the same string as above, I decided to split the string by the
/option tag. I used the following commands in a side-by-side comparison
(again in a loop of 5000):
preg_split( '/\/option/i', $string, $arr );
spliti( /option, $string, $arr );
explode( /option, $string, $arr );
The results:
preg_split
Timer: This page was generated in 0.23138296604156 seconds.
split
Timer: This page was generated in 0.22009003162384 seconds.
explode
Timer: This page was generated in 0.14973497390747 seconds.
This really is not too surprising when it comes to explode. If there is no
complex pattern matching, always use explode. preg_split vs split was a
little surprising given my findings above, but in general, it looks like
while there is not much of a difference, split has the slight edge.
Summary:
* If you are doing regular expression matching in a string, use preg_match.
Not only is it much faster, but it is much more powerful than ereg.
* If you are splitting a string by a simple string pattern, use explode.
* If you are splitting a string using regular expressions, use split unless
you need the functionality of preg_split.
Disclaimer:
I have not done exhaustive performance study of all of the possible
scenarios to find discrepancies, but from my observations so far, the above
conclusions have held true. If anyone has any other information, please
post it for us all to share. I hope some of you have found this useful.
Matthew Aznoe
Fuzz Technologies
[EMAIL PROTECTED]
(406) 587-1100 x217
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP] Submitting Form Information
Is there a way to simulate a form submission to a cgi-script using PHP? I am trying to write a script that will replace the frontend of another CGI script with a customized one of my own, but I need to be able to pass form data into the next page in the cgi (including a password). Matthew Aznoe Fuzz Technologies [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP] I love/hate FrontPage - need another HTML editor.
Have any of you tried using EditPlus? (www.editplus.com) This is a great little editor for HTML, JavaScript, and PHP. You can download extra modules for color syntax hilighting of practically any language you can think of including many different databases. It has some nice useful HTML features and good handling of multiple documents... and most importantly, you don't have to worry about it mangling your code. It is helpful while also staying out of your way. The more I use it, the more I like it. It is simple, elegant, and it gives me all the control that I want. Its inexpensive and comes with a thirty day trial. Check it out. BTW, I do not work for EditPlus or have any association with them other than that of a satisfied customer. Matthew Aznoe -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP] I love/hate FrontPage - need another HTML editor.
Sadly, no. As far as I know, it is a completely windows product. I am currently developing on a Windows box using Samba to access the files on my UNIX box from windows. Its not necessarily the best way of doing things and it requires two computers, but it seems to get the job done, and since I need to use Windows anyway for my company's standards of MS Office and Outlook, its tolerable. When running exclusively in UNIX, I run Elvis, a graphical vi with syntax hilighting. XEmacs also is not a bad option, but Elvis is much faster. Matthew Aznoe -Original Message- From: Scott Gerhardt [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 17, 2001 9:54 AM To: [EMAIL PROTECTED]; Php-General-Digest; Chris Aitken Subject: RE: [PHP] I love/hate FrontPage - need another HTML editor. It is NOT ported to Linux is it? I couldn't find any information on the website indicating weather it was compiled for *NIX or not. - Scott Have any of you tried using EditPlus? (www.editplus.com) This is a great little editor for HTML, JavaScript, and PHP. You can download extra modules for color syntax hilighting of practically any language you can think of including many different databases. It has some nice useful HTML features and good handling of multiple documents... and most importantly, you don't have to worry about it mangling your code. It is helpful while also staying out of your way. The more I use it, the more I like it. It is simple, elegant, and it gives me all the control that I want. Its inexpensive and comes with a thirty day trial. Check it out. BTW, I do not work for EditPlus or have any association with them other than that of a satisfied customer. Matthew Aznoe -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
