editing perl script through TEXTAREA

[Gunnar Hjalmarsson]

You know as well as I do that CGI.pm isn't telepathic: it gets fed
exactly the same data stream as any other CGI process would get
fed.

Yep. My comment was triggered by other posts in this thread with the
usual, awfully tiresome "CGI.pm takes care of it all" message.

 

[Alan J. Flavell]

Yep. My comment was triggered by other posts in this thread with the
usual, awfully tiresome "CGI.pm takes care of it all" message.

This is unworthy of you. The fact that CGI.pm is subject to the same
interworking rules as every other CGI software should come as no
surprise, and by trying to use it as a weapon to beat down those who
recommend the use of CGI.pm, you're more likely to weaken your own
argument than to strengthen it. IMHO. Now let's put this sub-thread
aside, and get back to substantive matters.

all the best

 

[Gunnar Hjalmarsson]

This is unworthy of you. The fact that CGI.pm is subject to the
same interworking rules as every other CGI software should come as
no surprise, and by trying to use it as a weapon to beat down those
who recommend the use of CGI.pm, you're more likely to weaken your
own argument than to strengthen it. IMHO.

Please wake up, Alan!

Previously in this thread, Xho and gnari discussed a fictitious need
for a "reverse convertion" of HTML entities, and claimed that CGI.pm
addresses that non-issue. Is it "unworthy" to react to misinformation?

Now let's put this sub-thread aside, and get back to substantive
matters.

Yes, now.

 

[gnari]

[snip familiar tirade about CGI.pm]

Previously in this thread, Xho and gnari discussed a fictitious need
for a "reverse convertion" of HTML entities, and claimed that CGI.pm
addresses that non-issue. Is it "unworthy" to react to misinformation?

I admit having mixed up htmldecoding and urldecoding on the part
of param(), so there is no 'reverse' convertion as such, but the fact
remains that param() decodes the form data and textarea() encodes it.
what is the problem ?

I think you are much too sensitive on this topic. no one is doubting
your abilities to write decent replacements for these functionalities,
but it is simpler and safer to tell a relative newbie to use CGI.pm

now, I would rather return to the previous and more interesting
subject of the problem with non-ASCII characters in form submissions.

what strategies are used to deal with this problem ?

gnari

 

[Gunnar Hjalmarsson]

I admit having mixed up htmldecoding and urldecoding on the part of
param(), so there is no 'reverse' convertion as such, but the fact
remains that param() decodes the form data and textarea() encodes
it. what is the problem ?

The OP had misunderstood what's happening when you submit a form with
a textarea control, and needed a clarification. Instead she was
incorrectly advised that using CGI.pm's param() would take care of 'it'.

I think you are much too sensitive on this topic. no one is
doubting your abilities to write decent replacements for these
functionalities,

The fact that a bunch of regulars here have done just that might
explain your perception of me being too sensitive. ;-)

But my objection this time stands for itself. It's important that
people who use CGI scripts gain a basic understanding and insight
about what's happening, about the implied security risks and the need
to validate data, etc. Repeatedly hearing regulars here attribute
things to CGI.pm, that the module was never designed to handle,
counteracts that 'mission'.

it is simpler and safer to tell a relative newbie to use CGI.pm

Absolutely. Therefore I used it in the script I posted in this thread.
But it can cause confusion, as in this case, if you give that advice
for the wrong reason.

 

[ctcgag]

Please wake up, Alan!

Previously in this thread, Xho and gnari discussed a fictitious need
for a "reverse convertion" of HTML entities, and claimed that CGI.pm
addresses that non-issue. Is it "unworthy" to react to misinformation?

I refered to conversion of special characters. I really don't
care whether they are html entities or URI encoded entities or the
Crystalline Entity while they are on the other side of the abstraction.
The point is, CGI nearly always will properly encode your text going into
the html form, and properly decode it coming back from a form submission.
If you want to know how it does it, look at how it does it. If it doesn't
do it quite right in some special circumstances, use it as a starting point
for making something that does do it right.

Xho

 

[Gunnar Hjalmarsson]

I refered to conversion of special characters. I really don't care
whether they are html entities or URI encoded entities or the
Crystalline Entity while they are on the other side of the
abstraction.

So you think it's unnecessary to understand anything about what's
happening behind the scenes when you are dealing with CGI? I for one
disagree on that. Strongly. You'll encounter problems very soon if you
don't have a basic understanding.

The point is, CGI nearly always will properly encode your text
going into the html form, and properly decode it coming back from a
form submission.

You seem to take for granted that CGI.pm is used for generating HTML,
while many (most?) people who deal with CGI choose to not use CGI.pm
for that purpose. They (we) do need to understand when converting
certain characters to HTML entities is necessary and how you do it.

If you want to know how it does it, look at how it does it.

There are far easier ways to gain a basic knowledge about CGI than
studying the CGI.pm source code, aren't there?

 

[Alan J. Flavell]

There are far easier ways to gain a basic knowledge about CGI than
studying the CGI.pm source code, aren't there?

Yes: you wouldn't want to study the source code without the basic
knowledge. But the basic knowledge is only the starting point to
practical expertise in deploying CGI scripts in the hostile light of
a WWW situation.

(I thought we'd agreed to draw a line under this, but anyway...)

While the CGI.pm user is learning the details, CGI.pm is taking care
of the basic blunders that they're likely to make. Whereas those who
insist on hand-knitting their own code (which is commendable enough as
a learning experience) and then making the mistake of actually using
it in production in a WWW environnment, are doomed to producing open
mail relays, web proxies, and heaven knows what else before they get a
proper feeling for web security.

In that sense, those who know *enough* to be able to write their own
code safely have no need of our advice here - but those who need to
ask would be better steered towards peer-reviewed modules such as
CGI.pm unti such time as they're ready to take their own decisions.

I think I'm ready to take my own decisions now, and 9 times out of 10
my decision is to choose CGI.pm. That 1 exception probably causes me
more work than all the other 9 added together.

good night

 

[Gunnar Hjalmarsson]

While the CGI.pm user is learning the details, CGI.pm is taking
care of the basic blunders that they're likely to make. Whereas
those who insist on hand-knitting their own code (which is
commendable enough as a learning experience) and then making the
mistake of actually using it in production in a WWW environnment,
are doomed to producing open mail relays, web proxies, and heaven
knows what else before they get a proper feeling for web security.

In that sense, those who know *enough* to be able to write their
own code safely have no need of our advice here - but those who
need to ask would be better steered towards peer-reviewed modules
such as CGI.pm unti such time as they're ready to take their own
decisions.

I don't believe it: You did it again!! In effect you just said that as
long as you use CGI.pm, you don't need to know about web security,
since CGI.pm takes care of it for you. Still you know much better than
most of us that nothing could be more wrong than just that.

- Using CGI.pm does *not* prevent anybody from unintentionally create
open mail relays.

- Using CGI.pm does *not* make it less important to validate incoming
data.

- Using CGI.pm does *not* (automatically) protect you from DoS
attacks.

- CGI.pm is *not* a generic cure against stupidity.

Instead of making such statements, and with that lull the beginners
into a false security, why don't you point people to documents such as

http://www.faqs.org/faqs/www/cgi-faq/preamble.html

http://www.w3.org/Security/Faq/www-security-faq.html

Then you would help them prepare their defense "in the hostile light
of a WWW situation" as you put it in a part of your message that I
just snipped...

P.S. CGI.pm is a convenient tool-box when creating CGI apps. I'm not
arguing against the use of it. It does take care of some "basic
blunders" with respect to functionality, but only to a very limited
extent with respect to security.

 

[Alan J. Flavell]

While the CGI.pm user is learning the details, CGI.pm is taking
care of the basic blunders that they're likely to make.

[...]

I don't believe it: You did it again!! In effect you just said that as
long as you use CGI.pm, you don't need to know about web security,

That wasn't my intention.

- CGI.pm is *not* a generic cure against stupidity.

Correct. But refusing to use CGI.pm is even less a cure against
stupidity.

into a false security, why don't you point people to documents such as

http://www.faqs.org/faqs/www/cgi-faq/preamble.html

Well recommended, from a well-respected author in the field

http://www.w3.org/Security/Faq/www-security-faq.html

whose author is - guess who...

Yes, I fully support that part of your campaign.

P.S. CGI.pm is a convenient tool-box when creating CGI apps. I'm not
arguing against the use of it. It does take care of some "basic
blunders" with respect to functionality,
Indeed.

but only to a very limited extent with respect to security.

On the one hand it's certainly possible to use it to implement some
blatantly insecure applications (e.g as open relay, as you mentioned).
On the other hand it internally protects against some rather obscure
and non-obvious exposures (for example that rather complex field
discussed in CERT CA-2000-02) before the naive beginner even starts to
grasp their implications.

 

[ctcgag]

You seem to take for granted that CGI.pm is used for generating HTML,

If I was taking that for granted, I would be pretending this thread did not
exist, which means I wouldn't be replying to it.

while many (most?) people who deal with CGI choose to not use CGI.pm
for that purpose.

I don't use CGI for generating generic html (<H1><p><em>, etc.) but
do use it for generating form element tags, and escaping form element
values. It does a good job.

They (we) do need to understand when converting
certain characters to HTML entities is necessary and how you do it.


There are far easier ways to gain a basic knowledge about CGI than
studying the CGI.pm source code, aren't there?

If by "easier", you mean "require less work to get something that doesn't
work well" then I suppose you are right. But when I want to both
understand it and have an implementation that works, I find that reading
and copying it out of the CGI source is the easiest way to do it.

Xho

 

[anita]

An XY problem is when you want to do X, but you ask how to do Y

instead, because you've decided that Y is the best way to accomplish X.
Ah.

If you tell us why you think you want to edit programs in a browser,

I just want to be able to edit programs through a browser using plain
HTML, without writing plug-ins, or browser addons or mapping an
application through MIME types to edit my file...

then maybe we could suggest a better or easier alternative...

The end in this case is the "how" not the end result itself. Or maybe
an explanation of why its not advisable to edit something through the
browser if I wanted to.
Thanks everybody for the different insights, in this thread.