Barring security issues:
Well, you can do it that way ... or you could set up
a "widget" called signed_up.tmpl:
<b>Signed up:<b>
<table><tr><td><tmpl_var data><\/td><\/tr>
<\/table>
Include that in the main page:
<tmpl_include signed_up.tmpl>
And just make sure that the HTML::Template object
responsible for populating the main page handles that
<tmpl_var data> tag. I discuss this technique
more at 3Re: HTML::Template - complex sites. Feel free to play with the code i
have posted there.
Now then, as for security ... if you don't want to allow
your users to submit HTML, the easiest hack you can do is:
my $data = '<html>evil tags!!</html>';
$data =~ s/</</g;
This will convert all < characters to <
which will effectively keep the tag from rendering.
jeffa
L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)
| [reply]
[d/l]
[select] |
$data =~ s/</</g;
If you're going to do that, you may just about as well
do it all the way:
use HTML::Entities; $datum=encode_entities($datum);
Though I admit your solution is probably faster and
yet will probably get the job done.
The problem arises when you do in fact need to allow
some HTML through. Another poster suggested to decide
on a list of permissible tags and strip all others.
I agree with that as far as it goes, but you also want
to strip certain attributes (notably, any that
start with the word 'on', case-insensitive) regardless
of what tag carries them, and if you're concerned about
the sort of games that can cause browsers to hang,
crash, or just plain not show the page, you probably
also want to reject (or encode entities on) anything
that doesn't meet some minimal standard of structure;
it's relatively easy to check wellformedness, though if
you want to allow legacy HTML4 and earlier you have to
do a little more work. At minimum, though, you probably
don't want to allow any tag to be closed that wasn't
opened, and you almost certainly want to be sure that
any table-related tags that are opened are also closed.
This starts to get messy, and personally I've gone with
the approach of putting the burden on the person who
is submitting the HTML: if it's not wellformed, I
pass it through encode_entities(), warn them that I've
done so, and provide a link to an explanation of what
wellformedness means and why it's useful. Because of
the way browsers automatically decode entities, even
in the values in form elements, they can then directly
edit their content to fix it up, and if they get it
wellformed on the next submission it'll go into the
database as-is. Whether you can take this approach
will depend somewhat on how much burden of quality
you're willing to place on the people writing the
HTML in question.
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,".rekcah lreP rehtona tsuJ";$\=$ ;->();print$/
| [reply]
[d/l]
[select] |
For my web site, I wrote a perl module that cleans up user submitted html, by only allowing sanctioned html tags to pass through. So, you can allow <P> and <b> but not anything else if you wanted.
I intended to submit it to cpan, but never had the time. Anyway, you can download it here: HTMLCleaner.pm.
It's got pod documentation. And if anyone wants to develop it, they are free to do so.
| [reply]
[d/l]
[select] |
It depends on whether $data is under the user's control or not.
If it is, it's best to prevent all HTML. I usually use an HTML escaping module, like the escapeHTML function provided by CGI.
Otherwise, if a malicious user can trick a legitimate user into setting $data to some Javascript code, the malicious user can steal cookies for your domain, or any other information in the page or the form.
| [reply]
[d/l]
[select] |