FW: Processing Password Questions

[Kenneth Brody]

(Coming in late in the discussion...0

Quoting Fairlight (Thu, 29 Dec 2005 12:48:34 -0500):

> Nancy Palmquist cast forth these immortal, mystical words:
[...]
> > The reason these get assigned incorrectly is people do not know they
> > did it.  There is a choice on the menu.  They choose it for some
> > reason - did not understand what it did, or thought it did something
> > else or just hit a wrong key (I like the cat on the keyboard option
> > myself).  In
>
> THANK YOU for making my point for me:  USER ERROR.
>
> I believe I already said that.

I think everyone here would agree that it's user error that would cause
a problem.  However, I believe what Nancy's point is that, if you don't
set a site password, and the "user error" occurs to add a site password,
there will be no indication that one has been added.  New processing
tables will be created with this unknown password, any time you save an
existing processing table which does not yet have a password (as is the
case for all prc files on the system) the password will be silently
added, and any time you bring up a prc file which has the password in
it, no prompt asking for it will be given (because it matches the site
password).  Now, the moment the iles are moved to a new system, or if
someone removes the "garbage" from the 4th line of the fppath file,
filePro will now "magically create" a password in all of the prc files
that you try to edit/debug.

But, if you were to create a site password (even if it's simply the
word "password"), then the above can't accidentally occur.  First, the
sitepwd progam will, by default, not ask for a new password if one is
already set, so you can't "accidentally" set one.  Second, if someone
were to explicitly change the password, filePro will immediately start
asking for the prc password when you edit/debug any table with the old
password in it, so it won't go unnoticed for years.

Finally, you can also set the password to nothing, which is not the
same as not set at all.  This will now create/save prc files with an
empty password in it.  This will prevent the "accidental" changing of
the site password, as above.  However, I don't recall if filePro will
ask for the prc password if the site password is changed in this case.

> > The discussion was to illuminate the use, function and pitfalls.  I am
> > sure it is entirely outside your experience when due to ignorance or
> > curiosity something happens you do not expect.
>
> I either 1) don't futz with something that I'm not familiar with, 2) I
> read up on it in advance so I -do- know WTH I'm going to be doing, or
> 3) if I really and truly screwed up, I track down the cause and make
> damned sure I never do it again.  Option 3 is a last resort fallback
> position.

Unfortunately, not everyone is able to control their users and prevent
them from futzing with things they shouldn't.

You'd be surprised (well, probably not) how many times people have
moved their files to a new system, only to have filePro "magically"
add a password to all of their prc files.  And, they will insist with
their dying breath that the old system didn't have a password.  Of
course, a check of their old system (if it's still avaiable) will show
that their fppath file does indeed have a password in it, and that it
hadn't been touched in 5 years.  (This is the downside, as you have
pointed out.)  Usually, the fastest way to deal with this is to have
them copy the 4th line from the fppath file to the new system, though
of course they're still left with an "unknown" site password.  Of
course, we luck out sometimes, and trying passwords like "n", "no",
and "password" sometimes works.  (This is usually a result of the old
install which asked for a site password at install time.)

[...]

--
KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
http://www.hvcomputer.com
http://www.fileProPlus.com