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
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
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 e
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 u
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.
On Mon, 23 Mar 2009 14:11:28 -0700 (PDT)
RebeccaJ 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 htmlentities(), pg_escap
On Mon, Mar 23, 2009 at 3:11 PM, RebeccaJ 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:
> http://www.postgresql.org/docs/8.3/static/multiby
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 thi
On Mon, Mar 23, 2009 at 01:07:18AM -0600, Scott Marlowe wrote:
> On Mon, Mar 23, 2009 at 12:59 AM, Stephen Cook 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 an
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
> wrote:
> > On Mon, 23 Mar 2009 01:07:18 -0600 Scott Marlowe
> > wrote:
> >> Are you saying pg_quer_params is MORE effective than
> >> pg_escape_string at deflecting SQL inje
On Mon, 23 Mar 2009 03:30:09 -0600
Scott Marlowe 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 warning for some
On Mon, Mar 23, 2009 at 2:33 AM, Ivan Sergio Borgonovo
wrote:
> On Mon, 23 Mar 2009 01:07:18 -0600
> Scott Marlowe wrote:
>
>> On Mon, Mar 23, 2009 at 12:59 AM, Stephen Cook
>> wrote:
>> > You should use pg_query_params() rather than build a SQL
>> > statement in your code, to prevent SQL inject
On Mon, 23 Mar 2009 01:07:18 -0600
Scott Marlowe wrote:
> On Mon, Mar 23, 2009 at 12:59 AM, Stephen Cook
> 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 s
On Mon, Mar 23, 2009 at 3:07 AM, Scott Marlowe 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 of the form " and
foo=$
On Mon, Mar 23, 2009 at 12:59 AM, Stephen Cook 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 there
> is no rog
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
htmlentitie
On Sun, Mar 22, 2009 at 11:36 AM, RebeccaJ 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 happen t
> > 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
On Sat, Mar 21, 2009 at 11:13 PM, RebeccaJ 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 table with
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, whe
20 matches
Mail list logo
