New webpage

[Fairlight]

>From inside the gravity well of a singularity, Bud Henschen shouted:
> As of this date, if you go to www.fptech.com you will find a new look for
> fP Tech and filePro.  There are still some things that we would like to
> add to it and delete from it, so take a look and give us you impression.
> If you find an error, let us know.  We ran it past the Alpha testers
> prior to release, but we may have missed something and would appreciate
> you notifying us if you find an error.
>
> BTW this didn't take away from FP programming but provided by my
> webmaster.

Bud,

First, let me compliment you HEARTILY on the new web site.  This is -THE
BEST- I've ever seen the site look.  It's clean, professional, has decent
layout, isn't bloated as all get-out with cruft, and it looks fantastic!
Your webmaster is to be commended.

ESPECIALLY welcome is the reversion to pure HTML and CSS of all the things
that were previously gratuitously -only- in PDF format.  Again, a FANTASTIC
move!

I cannot lavish upon you enough praise for having the site sensibly
redesigned.  Seriously...it SO needed what it got, here!  I'd suggest
-keeping- that web designer, as they are one of the minority that have a
clue on keeping a site both stylish -and- minimalistic, without veering off
into all the active content glitz and flash (literal and figurative).

All those compliments given, how soon do you want the active content side
of the site to make the fP-driven part unusable?  :( 

The site's reliance on fPcgi (the "Powered by fPcgi" was kind of a
giveaway), and the lack of use of the "server side only configuration" for
the actual commands makes it susceptible to a denial of service attack
that's very inexpensive to launch, but would make fP unusable on the web
server.  Let's take an example so you know why I'm seriously bringing it up
as a legitimate problem:

The page:
http://www.fptech.com/Products/Demos/reqddemo.shtml

Contains the following fPcgi related field code:
<input type="hidden" name="Field_cmd" value="rreport emailreg -sr 1 -fp
demonew -N">

If one took out 'emailreg' or just truncated the command after 'rreport',
filePro itself would sit there waiting for a file name on which to work.
If the server is *nix based, the race condition in filePro that I submitted
as a bug report a few days ago would kick into place, and the system could
be loaded -very- heavily in short order.  Even if the environment variables
for timeout and kill of the filePro clerk or report process were set,
unless they're set to something -very- small, an inexpensive attack could
be launched that would keep re-locking all your user licenses for filePro
on that server.  They keep getting killed, the attacker could just launch
more indefinitely.  On the server end, there's a time (even using the
variable that was introduced at my urging) for which it will wait for the
process to complete.  Race condition notwithstanding (assuming Ken fixes
that), user license count can be eaten as fast as someone can make forged
requests and break the connection--far faster, in fact, unless you don't
wait at all, which would make it pointless to have because it wouldn't be
usable to get/post any data.

The -only- way to secure this site against such an attack is to use the new
"include" file syntax for fPcgi 2.0 and take -ALL- the commands on -EVERY-
form internal, and disallow use of field_cmd[N], which if memory serves was
the other environment variable introduced in 2.0, also at my urging.

If the client side gets to determine which commands are run, the site has
security issues, plain and simple.  It's a design flaw in fPcgi, and the
new site should have used the 2.0 features to mitigate this problem.  This
requires a conscious redesign of -ALL- those areas that rely on fPcgi, so
that the commands are hardwired on the server, not sent as part of the HTTP
request from the client.  They -all- have to be rewired, because fPcgi
should be configured site-wide to disallow remote commands for precisely
these reasons.  If you allow -any- remote commands, even if code appears
nowhere on a form, then you have a problem.  What I'm trying to convey here
is that just redesigning each page to use internal-only is not enough.  You
have to disable external field_cmd[N] site-wide, or anyone can spoof a
request to fPcgi and launch the same attack, lack of page notwithstanding.
You don't need page source to launch an attack, trust me on this.

The site -LOOKS- great.  Again, I'm -very- impressed, given the history of
poorly designed sites that were previously implemented.  Best delivery I've
ever seen you folks put together.

But it does have security issues, even if that timeout is set intenally,
and even if it's set to one second (which would in effect make it useless
for actually using fP from the web site).  In other words, it -has-
security issues.

Sorry for the bad news.  But hey--I -am- impressed with the appearance.

The business comment I have is that, again, there is a complete lack of
pricing information available until you get to "Confirm Pricing" while
actually ordering a product.  I don't know anyone that will blindly order a
product without knowing the price up front.  You really should have a
conspicuously labled and prominent section for "Pricing" on your site.
If someone has to go to contortions to get a price check, chances are
they're -gone-, as in lost sale, they're elsewhere.  I know if I can't find
a price somewhere, I won't even bother.  I just keep looking for someplace
that has stated pricing.  If there -is- a price list, it's not evident.
Even the individual product pages don't have their own price lists, and
there's certainly not a central list.

Also, "Purchase" is in the ring menu at the footer of the pages, but does
not appear in the menu buttons at the top of each page.  It should probably
be adjusted to be symmetrical.

Ah, and you worked in the help file documentation.  VERY nice.  Might want
to have someone try that with FireFox though.  I'm using FireFox 1.0.7,
and I'm doubting that browser-wide white box in the middle of the default
background behind the documentation applet is intentional.  Tiny quirk,
probably fixable.

Overall, great job!  I'm impressed!

Bests,

mark->