br html line breaks and htmlentitities

[pittendrigh]

I have a home-rolled forum, written in php, based
on some old cgi code written by a guy named David Turely.
Works just fine.

However, when reading user-supplied input I use 'addslashes'
to clean the possibly tainted data.

On subsequent displays the user-supplied data comes
off the file system, so I do a stripslashes and then
an addslashes (prevents single quotes from multiplying
in quoted parts of the threads).

However, this does put one annoying slash before single
quote in the text, that looks ugly in the output.

If I use htmlentities on the data instead of addslashes,
everythink looks fine, except for incoming newlines,
which don't translate into real <br/tags,
so the text all runs together as one long sentance.

If anybody understands what I'm gibbering about,
maybe they also have a solution:

How do I scrub user-supplied input so it is safe to
display, and so single quotes are not visually escaped,
and so real <br/tags appear at the end of each line?

Seems to me like regular expressions allowing real html
for <br/tags *only* has to be part of the deal. But I
don't know how to handle the ugly, visually escaped
single quotes.

[Jerry Stuckle]

Re: br html line breaks and htmlentitities

pittendrigh wrote:

I have a home-rolled forum, written in php, based
on some old cgi code written by a guy named David Turely.
Works just fine.
>
However, when reading user-supplied input I use 'addslashes'
to clean the possibly tainted data.
>
On subsequent displays the user-supplied data comes
off the file system, so I do a stripslashes and then
an addslashes (prevents single quotes from multiplying
in quoted parts of the threads).
>
However, this does put one annoying slash before single
quote in the text, that looks ugly in the output.
>
If I use htmlentities on the data instead of addslashes,
everythink looks fine, except for incoming newlines,
which don't translate into real <br/tags,
so the text all runs together as one long sentance.
>
If anybody understands what I'm gibbering about,
maybe they also have a solution:
>
How do I scrub user-supplied input so it is safe to
display, and so single quotes are not visually escaped,
and so real <br/tags appear at the end of each line?
>
Seems to me like regular expressions allowing real html
for <br/tags *only* has to be part of the deal. But I
don't know how to handle the ugly, visually escaped
single quotes.
>

You should use htmlentities() to display data in html. <brtags are
handled by nl2br().

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===

[Richard Levasseur]

Re: br html line breaks and htmlentitities


pittendrigh wrote:

I have a home-rolled forum, written in php, based
on some old cgi code written by a guy named David Turely.
Works just fine.
>
However, when reading user-supplied input I use 'addslashes'
to clean the possibly tainted data.
>
On subsequent displays the user-supplied data comes
off the file system, so I do a stripslashes and then
an addslashes (prevents single quotes from multiplying
in quoted parts of the threads).
>
However, this does put one annoying slash before single
quote in the text, that looks ugly in the output.
>
If I use htmlentities on the data instead of addslashes,
everythink looks fine, except for incoming newlines,
which don't translate into real <br/tags,
so the text all runs together as one long sentance.
>
If anybody understands what I'm gibbering about,
maybe they also have a solution:
>
How do I scrub user-supplied input so it is safe to
display, and so single quotes are not visually escaped,
and so real <br/tags appear at the end of each line?
>
Seems to me like regular expressions allowing real html
for <br/tags *only* has to be part of the deal. But I
don't know how to handle the ugly, visually escaped
single quotes.

You can use nl2br() for changing newlines to <br/(actually, i think
nl2br() *may* respect the current DTD, but don't quote me on that).

You can use htmlentities to santize the data.

The additional slash may be coming from the "magic quotes" options of
PHP.
See http://us2.php.net/manual/en/security.magicquotes.php for more
information. Make sure it is turned off because it causes headaches
like the ones you describe.

What may have happened by now is that you've been running with magic
quotes enabled, so a portion of your data contains a literal \'. If
thats the case, you'll have to identify those records and fix them
manually since its not a display bug, its a problem with the data.
Very annoying, i know. A simple find/replace for \' should be able to
fix it, more or less.