× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Brad Stone wrote:
> ...
> Yes, the web works great for simple order history, customer
> service, and ordering.  But that's because these people are
> outside of the business and don't need to know everything to
> the last detail.  Just the basics.  Perfect fit for the web.
> And the biggest reason, it needs to be an app that everone
> can get to.  Web again is perfect for that because we can't
> control what the customer is using to access the data.  We
> can just make sure it's a web browser.
> ...

Forgive me for butting in and nitpicking.  While almost everything
you say in your note is certainly correct, the last sentence in the
above paragraph is not.  You just can't guarantee that a hit on your
public web site is from a web browser (let alone any particular
browser).  The request may be coming from any of hundreds of
webbots, such as the "Googlebot" or the infamous "email siphon".
Or, the request may even be coming from some malicious script kiddie
using a tool like your GETURI.

For the benefit of newbies to CGI programming, why is this important
to understand?  It is vitally important to assume that all inputs
are not to be trusted, and to verify all inputs coming into your CGI
program.  Every parameter name and every parameter value should be
checked, otherwise you run the risk of someone crashing your
program.  In fact, I've seen several RPG CGI programs in published
form from various authors that can be easily crashed with invalid input.

(BTW, Perl CGI programmers are familiar with an incredibly useful
feature of that language called "taint checking".  By using option
"-t" on the command, all inputs coming in are considered "tainted"
until explicitly accepted.  Tainted values cannot be used for many
operations where there's risk.  Unfortunately, this type of feature
is much harder to implement in a compiled language, like RPG, if not
impossible.)

The bottom line is this:  Regardless of any size limits in your HTML
forms, or any validity checking in your client-side scripting,
validity checking is a necessity in all CGI programs, since the
request may be coming from a source other than a supported browser.

Cheers!  Hans





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.