Daniel Verite wrote:
Note that htmlentities() expects LATIN1-encoded strings and is thus
unusable on UTF-8 contents.
So if you end up talking UTF-8 with the database, you'll probably need
to use htmlspecialchars() instead, and UTF-8 as your HTML charset.
I believe you are wrong, at least the
Stephen Cook wrote:
Daniel Verite wrote:
Note that htmlentities() expects LATIN1-encoded strings and is thus
unusable on UTF-8 contents.
So if you end up talking UTF-8 with the database, you'll probably
need
to use htmlspecialchars() instead, and UTF-8 as your HTML charset.
RebeccaJ wrote:
Thanks, everyone, for your contribution to this thread. I'm
approaching the database design of my web application differently,
now. Before, I was planning to have CHECK constraints in all of my
text or char fields, to keep out all semicolons, single quotes, and
anything
You should use pg_query_params() rather than build a SQL statement in
your code, to prevent SQL injection attacks. Also, if you are going to
read this data back out and show it on a web page you probably should
make sure there is no rogue HTML or JavaScript or anything in there with
On Mon, Mar 23, 2009 at 12:59 AM, Stephen Cook scli...@gmail.com wrote:
You should use pg_query_params() rather than build a SQL statement in your
code, to prevent SQL injection attacks. Also, if you are going to read this
data back out and show it on a web page you probably should make sure
On Mon, Mar 23, 2009 at 3:07 AM, Scott Marlowe scott.marl...@gmail.com wrote:
Are you saying pg_quer_params is MORE effective than pg_escape_string
at deflecting SQL injection attacks?
pg_query_params() will protect non-strings. For instance, read a
number in from user input and do something
On Mon, 23 Mar 2009 01:07:18 -0600
Scott Marlowe scott.marl...@gmail.com wrote:
On Mon, Mar 23, 2009 at 12:59 AM, Stephen Cook scli...@gmail.com
wrote:
You should use pg_query_params() rather than build a SQL
statement in your code, to prevent SQL injection attacks. Also,
if you are going
On Mon, Mar 23, 2009 at 2:33 AM, Ivan Sergio Borgonovo
m...@webthatworks.it wrote:
On Mon, 23 Mar 2009 01:07:18 -0600
Scott Marlowe scott.marl...@gmail.com wrote:
On Mon, Mar 23, 2009 at 12:59 AM, Stephen Cook scli...@gmail.com
wrote:
You should use pg_query_params() rather than build a SQL
On Mon, 23 Mar 2009 03:30:09 -0600
Scott Marlowe scott.marl...@gmail.com wrote:
I think pg_query_params should make a difference between floats
and integers and signal an error if you pass float where
integers are expected... but I'm not sure.
Not really a security concern, but an early
On Mon, Mar 23, 2009 at 03:30:09AM -0600, Scott Marlowe wrote:
On Mon, Mar 23, 2009 at 2:33 AM, Ivan Sergio Borgonovo m...@webthatworks.it
wrote:
On Mon, 23 Mar 2009 01:07:18 -0600 Scott Marlowe scott.marl...@gmail.com
wrote:
Are you saying pg_quer_params is MORE effective than
On Mon, Mar 23, 2009 at 01:07:18AM -0600, Scott Marlowe wrote:
On Mon, Mar 23, 2009 at 12:59 AM, Stephen Cook scli...@gmail.com wrote:
You should use pg_query_params() rather than build a SQL statement
in your code, to prevent SQL injection attacks. Also, if you are
going to read this data
On Mar 22, 12:36 pm, scott.marl...@gmail.com (Scott Marlowe) wrote:
ayup. As long as they're legal for your encoding, they'll go right in.
If you wanna stuff in anything no matter the encoding, use a database
initialized for SQL_ASCII encoding.
Thanks, everyone, for your contribution to this
On Mon, Mar 23, 2009 at 3:11 PM, RebeccaJ rebec...@gmail.com wrote:
Scott, your comment above introduced some new concepts to me, and now
I'm thinking about foreign language text and other ways to be more
flexible. I found this page that talks about encoding:
On Mon, 23 Mar 2009 14:11:28 -0700 (PDT)
RebeccaJ rebec...@gmail.com wrote:
now. Before, I was planning to have CHECK constraints in all of my
text or char fields, to keep out all semicolons, single quotes, and
anything else that looked dangerous. Now I'm thinking that I'll be
using
On Mar 23, 2009, at 10:11 PM, RebeccaJ wrote:
On Mar 22, 12:36 pm, scott.marl...@gmail.com (Scott Marlowe) wrote:
ayup. As long as they're legal for your encoding, they'll go right
in.
If you wanna stuff in anything no matter the encoding, use a database
initialized for SQL_ASCII encoding.
RebeccaJ wrote:
And I wonder why you like SQL_ASCII better than UTF8, and whether
others have any opinions about those two. (My web server's LC_CTYPE is
C, so I can use any character set.) Wouldn't UTF8 allow more
characters than SQL_ASCII?
I've had a LOT of experience dealing with apps that
Hi,
I'm new to both PostgreSQL and web-based application development; I
read the FAQ at postgresql.org (perhaps this discussion group has
another FAQ that I haven't found yet?) and didn't see this addressed.
I'm creating a table with a column of type text, to be used in a php
web application,
On Sat, Mar 21, 2009 at 11:13 PM, RebeccaJ rebec...@gmail.com wrote:
Hi,
I'm new to both PostgreSQL and web-based application development; I
read the FAQ at postgresql.org (perhaps this discussion group has
another FAQ that I haven't found yet?) and didn't see this addressed.
I'm creating a
Are there characters, maybe non-printing characters, or perhaps
even whole phrases, that could cause problems in my database or
application if I were to allow users to enter them into that column?
If so, does anyone happen to have a regular expression handy that you
think is a good
On Sun, Mar 22, 2009 at 11:36 AM, RebeccaJ rebec...@gmail.com wrote:
Are there characters, maybe non-printing characters, or perhaps
even whole phrases, that could cause problems in my database or
application if I were to allow users to enter them into that column?
If so, does anyone
20 matches
Mail list logo
