> This one caught me as well - most of my sites simply do not need
> security as the site is secure, or there is no monitor or keyboard.
> Plugging in the id is OK, but it adds to the remote work to a site
> when all I did in the past was pumped over the program. I am being
> asked to reduce setup steps, not increase it.

You need to blame me for this stuff - I'm the one that convinced Jason
that the storage of passwords was dangerous. I was dismayed to see
passwords being spread about accidently as people shared their project
files and executables etc.

So the current arrangement is intentional - setting
PasswordRemembered=true will intentionally restrict access to the
current user (by default). There are ways to change this but they are
not currently obvious (or available by property setting). I fully
intended that people should be forced to hardcode their passwords if
that was really what they wanted to do. The idea being that it should
take effort to be insecure, and reasonable security should be the
default.


So the question becomes...

Do I set about changing IB_Connection so that there is some property
based mechanism whereby you can avoid the protection mechanisms OR do
we simply insist that developers hardcode their passwords if that is
what they want?

You can probably guess that the latter was and still is my preference
:-) Is there a problem with putting your password in the code at that
point (it only has to be assigned sometime between loading the
form/module containing the connection and actually connecting to the
database). I like this approach because it makes it clear to you the
developer that you are hardcoding the password, when it was simply
stored in the DFM very few realised it remained sitting there in plain
text (even if you later added a prompt).


And some words about security...

It is not just a matter of whether the individual users need to be
authorised, but also whether the client is happy that...

1. The users can easily discover the password and access the
database with ANY program (such as IB_SQL etc).

2. That anyone with access to the program can discover the password
and access the database (presuming they can establish a connection) -
again with any program.

3. Security cannot be improved in the future without recompiling the
program.


Now that I've had my say ;-) you are welcome to tell me that you still
want a property on the IB_Connection that will let you store the
password in the DFM without any protection at all. (You wont convince
me to make that the default, but you may convince me that it is
appropriate to have it as an option.)


Geoff Worboys
Telesis Computing