Re: [PHP] Htmlentities vs htmlspecialchars
On Wed, 26 Jul 2006 14:59:46 +0200, Jochem Maas wrote: I wonder if anyone can given a solid answer to this? If I remember correctly, htmlspecialchars does what its name indicate: konvert any character with special meaning according to the HTML specification. htmlentities converts any character to its HTML representation. One caveat of using htmlentities is that it is really hard to read for a human being, but as long as the output is only used inside a browser there is no problem. Nowadays I do a lot of XML stuff which only leaves one option: htmlentities. Another thing: PHP is designed to be used on the web in browser so htmlspecialchars, in my opinion, is redundant. -- Hilsen/Regards Michael Rasmussen http://keyserver.veridis.com:11371/pks/lookup?op=getsearch=0xE3E80917 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Zend Studio, phpMyAdmin, and mysql.sock
On Sat, 15 Jul 2006 00:57:18 +0900, Dave M G wrote: In any case, this list is called PHP general. Am I really so unreasonable in thinking that asking about how to set up a PHP development environment so that I can debug my PHP scripts without it conflicting with the PHP database administration system is on-topic? In your Zend folder there is a folder called bin. In that folder you should see to other folders: php4 and php5. In each of those folders you should fine a file called php.ini. In that file add the following instruction: mysql.default_socket=/path/to/mysqld.sock -- Hilsen/Regards Michael Rasmussen http://keyserver.veridis.com:11371/pks/lookup?op=getsearch=0xE3E80917 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: Find out cookies on a computer?
On Fri, 30 Jun 2006 04:23:51 +0700, Peter Lauri wrote: Is it possible to some how find out all cookies on a specific computer and their name and value? I assume not :) The global array $_COOKIE should hold any cookie which is available to you -- Hilsen/Regards Michael Rasmussen http://keyserver.veridis.com:11371/pks/lookup?op=getsearch=0xE3E80917 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: Find out cookies on a computer?
On Fri, 30 Jun 2006 05:06:33 +0700, Peter Lauri wrote: Yes, but that is just for the ones available for me. Like Google, they set a cookie if you click on one of their adwords ads and then use them in the tracking of the customer conversion. The place where the cookies are stored is dependant of the users browser and platform. Try this by having MS IE and FF display all stored cookies - I bet you would get a different picture. -- Hilsen/Regards Michael Rasmussen http://keyserver.veridis.com:11371/pks/lookup?op=getsearch=0xE3E80917 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] xmldoc
On Fri, 23 Jun 2006 16:12:56 -0300, Mariano Guadagnini wrote:
xmldoc, which is found in the extension DOM XML is no longer part of
PHP as of PHP = 5.0. It has been replaced by DOM. See
http://dk2.php.net/manual/en/ref.dom.php
http://dk2.php.net/manual/en/ref.domxml.php
Maybe when parsing the xml, the function throws an exception. That
happened to me with PHP 5 xml builtin support, which uses libxml to
process xml's, it can be that your document is malformed, you could try
with a php debugger (like zend debugger).
There is really no need for debugger. Simple use the build-in exception
handler. The most sane advise would be this:
?php
$xmlfile = '/test/test.xml';
echo starting parsing xml;
try {
$doc = DOMDocument::load($xmlfile);
}
catch (Exception $ex)
{
echo $ex-getMessage();
}
echo done parsing xml;
?
--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=getsearch=0xE3E80917
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: mysql ORDER BY problem
On Sun, 18 Jun 2006 15:55:14 -0500, Rob W. wrote: Is there a way with my mysql query so that I can list the numbers in correct order? In what way is this problem related to PHP? Try a MySQL group instead. -- Hilsen/Regards Michael Rasmussen http://keyserver.veridis.com:11371/pks/lookup?op=getsearch=0xE3E80917 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Recode and OpenBSD
Hi all, Is recode broken in php4.3.3 on OpenBSD? When I try recode it returns an empty string! The same string used in mb* and iconv performs as expected. -- Hilsen/Regards Michael Rasmussen -- You would if you could but you can't so you won't. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] SQL Injection check (mysql)
On Tue, 23 Mar 2004 12:05:17 -0800, Pablo Gosse wrote: I think you have misunderstod the concepts of making queries based on user input. It is not the users who should create the query, all to should do is provide the input to narrow down the queries. I have not misunderstood the concepts of making queries based on user input. I was here refering to my definition and not in general terms. It was not ment to offend anybody:-) 1) Hard coding a query into an application is good, if the situation permits it; True. 2) Letting a user select (or enter) a value(s) to be used in a query is good, as long as you validate the hell out of said value(s); Also true. 3) Letting a user arbitrarily enter unvalidated value(s) to be used in a query is very very stupid and very very bad, and done far too often. Again, true. In a broader scope I would here consider to be user input ANY input which is not hard coded into the application, and any input which is not hard coded should be thoroughly examined before being used. I agree. -- Hilsen/Regards Michael Rasmussen -- Kiss me, Kate, we will be married o' Sunday. -- William Shakespeare, The Taming of the Shrew -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] SQL Injection check (mysql)
On Tue, 23 Mar 2004 08:25:32 -0800, Pablo Gosse wrote: A RARE case, in the world of web applications??? Hardly! I agree that in an optimal situation queries will not be based on user input, but in the world of the web this is a pipe dream. In 99.99% of the cases there will be some dynamic element to a query. The only safeguard is to validate the hell out of the data. I don't know which web applications you develop, but the ones I have be developing the last 10 years all user interaction was done thrue forms where users where asked specific question, and the input to these specific questions where used as input in prepared statements. Eg. select tuple1.table1, tuple1.table2, tuple3.table1 from table1, table2 where tuple1.table1 = tuple1.table2 and tuple1.table1=? and tuple3.table3? and so forth. In any case the users input where to be used in queries defined by the design of the application! I think you have misunderstod the concepts of making queries based on user input. It is not the users who should create the query, all to should do is provide the input to narrow down the queries. -- Hilsen/Regards Michael Rasmussen -- Beauty and harmony are as necessary to you as the very breath of life. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] SQL Injection check (mysql)
On Tue, 23 Mar 2004 09:27:29 -0800, Chris Shiflett wrote: This argument still makes no sense to me. Originally, you stated that a better option to filtering and escaping data was to use a prepared statement. Some of us have decided that you are referring to stored procedures. You still have yet to defend your original statement in my mind. If there is no foreign data of any kind in a query, it doesn't really matter how the query is processed. For every other case (not as rare as you seem to think), data filtering is a must. See my reply to Pablo Gosse. -- Hilsen/Regards Michael Rasmussen -- It was all so different before everything changed. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SQL Injection check (mysql)
On Sun, 21 Mar 2004 18:39:39 -0800, Chris Shiflett wrote:
Can you explain that (and defend it)?
The reason is security. A prepared statement cannot comprimize the
security of our database because all sql-statements are precompiled in the
DBMS. An example using pear:
$res = DB:connect('mysql://someuser:[EMAIL PROTECTED]/thedb');
$sth = $res-prepare('select * from sometable where id ?');
$sth-execute(10);
As the example demonstrates the request is hardcoded which means it cannot
be manipulated by any user supplied input. A beneficial side effect is
that all characters which need exscaping is automatically handled by the
DBMS. E.g the string O'leary would not cause any problems.
Another argument is, that it theoretically should run faster.
--
Hilsen/Regards
Michael Rasmussen
--
Be careful! Is it classified?
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] SQL Injection check (mysql)
On Mon, 22 Mar 2004 14:36:44 -0800, Pablo Gosse wrote: Huh? How does this accommodate for a dynamically generated query which is based upon user input? Have you read my arguments? A prepared statement cannot be dynamically generated! It is validated and its type set before it is inserted into the query, so how does what you state above deal with this? The idea is exactly not to do any queries dynamically generated based on user input! In the rare cases where this is needed you should not allow any unparsed input. -- Hilsen/Regards Michael Rasmussen -- You have a will that can be influenced by all with whom you come in contact. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] SQL Injection check (mysql)
On Sun, 21 Mar 2004 13:49:22 -0800, Chris Shiflett wrote: To be clear: make sure the data that the user submitted only contains the characters you think are valid (don't bother trying to guess malicious characters - you're sure to miss one) and is a valid length. Once you've done this, and your design helps you to make sure that this step can't be bypassed by the user, you're protected against SQL injection. Or even better: Use only prepared statements. -- Hilsen/Regards Michael Rasmussen -- Be cheerful while you are alive. -- Phathotep, 24th Century B.C. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
