Messing With Application Object From Another App

  • Thread starter Thread starter Dima
  • Start date Start date
D

Dima

Hi,

Is it possible to prevent a user from getting access to Access.Application
from another app via GetObject() and read properties or run methods
that he is not supposed to?

Thanks in advance.
 
If you apply user level security, and that user does NOT have valid account
information, then they would not be allowed access to the database.
 
Thanks Scott,

However if user DOES have a valid account or database has been left open by
someone who has such account what would prevent an unscrupulous person from
using application's Run method to run public subs or reading properties of
opened forms (e.g. a value protected by InputMask="Password") or using
DBEngine's cached connection information to run queries if an ODBC database
has been opened once in code? It seems that a developer, while being able to
protect the project's code, has no ability to ensure that his application is
used only by means of the interface and not via freely accessible Automation
which he may not intend to allow use of at all.

I would greatly appreciate your answer. Thanks.
 
If the user has sufficient knowledge, the proper credentials, and the
necessary object permissions you really can't stop them (of course, the
argument is that they shouldn't be given those permissions and credentials
if they are not trustworthy). They would have to have intimate knowledge of
the programs internals as well as knowledge of the table structure in order
to do this but yes, it could certainly be done. You can make life a little
harder by distributing your Access app as an .mde file (which removes the
design features, thereby not allowing users to browse your code) and using
only RWOP queries (and disallowing all access to your tables), but that just
raises the bar. As someone else stated, just by implementing security and
using RWOP queries, you've kept 99% of people out. Trying to keep out the
other 1% is hopeless.
 
Once an ODBC connection has been cached a database can be opened via
DBEngine by just supplying a DSN regardless of RWOPs. Of course I have to
implement security there for every user and figure out how linked tables
ought to be shared when a single user is stored in their Connect properties.
This Automation creates all these problems for more that it is worth. Why
not simply make it optional?

Happy New Year by the way (and apologies for pressing the wrong Reply
button).
 
If you have disallowed ALL access to ALL tables, then connecting to your
backend db by whatever means would allow them to run your stored queries but
would not allow them to add queries or run SQL Statements against your
tables (since they have NO permissions on your tables) ... and I personally
wouldn't use a DSN to connect ... instead, use one of the OLE DB or ODBC
DSN-less connect strings from www.able-consulting.com
 
Back
Top