Using Office 2003 and Windows XP;

I am developing a form for wide distribution that will be locked down fairly
well. I know anything can be hacked, the sole purpose is to discourage casual
mistakes and tampering that would generally compromise the programming built
into the form.

However, I need to build myself a back door into the form that will unlock
everything and restore certain menus that will be controlled, etc. This is
needed so that myself and another developer can periodically perform
maintenance on the form. I already have the unlocking code written, but what
is a good way to access it without a user stumbling onto the key?

Does anyone have any suggestions for how to "back door" my way into my own
locked down form once its placed into production?

All suggestions welcomed, please respond...thanks in advance.

You could use the Terminate Event on the userform to unlock these things.
However, if you prefer, you can also setup an input box or have it go to a
different user form for something like putting in a password to unlock
everything.

I also had a similar type situation in June of 2001 when I built my
production reporting system for the operators to report into. I mainly
password protected the worksheets, workbook, and VBA, which then I used code
to control a lot of the various things. Since I ran into issues of the Open
Event on the Workbook object not working at times when the workbook is
opened like it suppose to regardless if it's opened by way of user opening
or VBA opening. I ended up using the "Private Sub Auto_Open()" route to run
code that needs to be done just after the file itself is open. Now with
this route, it runs automatically if user opens the workbook, but it doesn't
run automatically if it's opened by VBA.

I not only had to have it locked down so as operators couldn't just make
adjustments, but also had to have a way to make adjustments to the various
individual files on an as needed basis. To this day, this reporting system
that I built in June 2001 over a 3 week period is still in place.

--

Sincerely,

Ronald R. Dodge, Jr.
Master MOUS 2000

"XP" <(E-Mail Removed)> wrote in message
news:4239B8C2-7C97-4D07-BDB7-(E-Mail Removed)...
> Using Office 2003 and Windows XP;
>
> I am developing a form for wide distribution that will be locked down
> fairly
> well. I know anything can be hacked, the sole purpose is to discourage
> casual
> mistakes and tampering that would generally compromise the programming
> built
> into the form.
>
> However, I need to build myself a back door into the form that will unlock
> everything and restore certain menus that will be controlled, etc. This is
> needed so that myself and another developer can periodically perform
> maintenance on the form. I already have the unlocking code written, but
> what
> is a good way to access it without a user stumbling onto the key?
>
> Does anyone have any suggestions for how to "back door" my way into my own
> locked down form once its placed into production?
>
> All suggestions welcomed, please respond...thanks in advance.
>

Why not go through the front door, supply correct password and unlock the
project.

If you don't want to view code and merely want some other menu or controls
made visible, eg

- check a certain cell for password
- click in a particular region of the form or some control, trap mouse X/Y
while say holding alt-shift
- password in a textbox
- combination of the above
- loads of ways !

In passing, in your other recent post did the very hidden wb suggestion work
for your purposes.

Regards,
Peter T

"XP" <(E-Mail Removed)> wrote in message
news:4239B8C2-7C97-4D07-BDB7-(E-Mail Removed)...
> Using Office 2003 and Windows XP;
>
> I am developing a form for wide distribution that will be locked down
fairly
> well. I know anything can be hacked, the sole purpose is to discourage
casual
> mistakes and tampering that would generally compromise the programming
built
> into the form.
>
> However, I need to build myself a back door into the form that will unlock
> everything and restore certain menus that will be controlled, etc. This is
> needed so that myself and another developer can periodically perform
> maintenance on the form. I already have the unlocking code written, but
what
> is a good way to access it without a user stumbling onto the key?
>
> Does anyone have any suggestions for how to "back door" my way into my own
> locked down form once its placed into production?
>
> All suggestions welcomed, please respond...thanks in advance.
>

Hi,

Yes, the workbook method you suggested is superb. I am already using it!
Thanks to that, I can now keep users from opening a form directly, instead
they must use a specific loading program that keeps macros running, etc.

Thanks...

"Peter T" wrote:

> Why not go through the front door, supply correct password and unlock the
> project.
>
> If you don't want to view code and merely want some other menu or controls
> made visible, eg
>
> - check a certain cell for password
> - click in a particular region of the form or some control, trap mouse X/Y
> while say holding alt-shift
> - password in a textbox
> - combination of the above
> - loads of ways !
>
> In passing, in your other recent post did the very hidden wb suggestion work
> for your purposes.
>
> Regards,
> Peter T
>
> "XP" <(E-Mail Removed)> wrote in message
> news:4239B8C2-7C97-4D07-BDB7-(E-Mail Removed)...
> > Using Office 2003 and Windows XP;
> >
> > I am developing a form for wide distribution that will be locked down
> fairly
> > well. I know anything can be hacked, the sole purpose is to discourage
> casual
> > mistakes and tampering that would generally compromise the programming
> built
> > into the form.
> >
> > However, I need to build myself a back door into the form that will unlock
> > everything and restore certain menus that will be controlled, etc. This is
> > needed so that myself and another developer can periodically perform
> > maintenance on the form. I already have the unlocking code written, but
> what
> > is a good way to access it without a user stumbling onto the key?
> >
> > Does anyone have any suggestions for how to "back door" my way into my own
> > locked down form once its placed into production?
> >
> > All suggestions welcomed, please respond...thanks in advance.
> >
>
>
>

Hi,

I haven't had the issue of the auto open, but I do know you can by pass it
by holding down the shift key if a file is opened normally.

Do you know if that was just a bug in an earlier version of XL that has been
fixed by now?


"Ronald Dodge" wrote:

> You could use the Terminate Event on the userform to unlock these things.
> However, if you prefer, you can also setup an input box or have it go to a
> different user form for something like putting in a password to unlock
> everything.
>
> I also had a similar type situation in June of 2001 when I built my
> production reporting system for the operators to report into. I mainly
> password protected the worksheets, workbook, and VBA, which then I used code
> to control a lot of the various things. Since I ran into issues of the Open
> Event on the Workbook object not working at times when the workbook is
> opened like it suppose to regardless if it's opened by way of user opening
> or VBA opening. I ended up using the "Private Sub Auto_Open()" route to run
> code that needs to be done just after the file itself is open. Now with
> this route, it runs automatically if user opens the workbook, but it doesn't
> run automatically if it's opened by VBA.
>
> I not only had to have it locked down so as operators couldn't just make
> adjustments, but also had to have a way to make adjustments to the various
> individual files on an as needed basis. To this day, this reporting system
> that I built in June 2001 over a 3 week period is still in place.
>
> --
>
> Sincerely,
>
> Ronald R. Dodge, Jr.
> Master MOUS 2000
>
> "XP" <(E-Mail Removed)> wrote in message
> news:4239B8C2-7C97-4D07-BDB7-(E-Mail Removed)...
> > Using Office 2003 and Windows XP;
> >
> > I am developing a form for wide distribution that will be locked down
> > fairly
> > well. I know anything can be hacked, the sole purpose is to discourage
> > casual
> > mistakes and tampering that would generally compromise the programming
> > built
> > into the form.
> >
> > However, I need to build myself a back door into the form that will unlock
> > everything and restore certain menus that will be controlled, etc. This is
> > needed so that myself and another developer can periodically perform
> > maintenance on the form. I already have the unlocking code written, but
> > what
> > is a good way to access it without a user stumbling onto the key?
> >
> > Does anyone have any suggestions for how to "back door" my way into my own
> > locked down form once its placed into production?
> >
> > All suggestions welcomed, please respond...thanks in advance.
> >
>
>
>

I haven't been able to locate the specific cause of it, but I do know it
most definitely wasn't fixed in XL2002. This issue impacted one of the
Excel files that is used as a template and widely distributed, which the
open event on the workbook object was no longer working on anyone's
computer, even with the security level set to "Low". I attempted all of the
updates, and that didn't help any either. For this very reason, I was
forced to use the "Private Sub Auto_Open()" procedure within a standard
module to get around this issue.

As a result of this issue, it now gives people a back door way into the file
and is in many ways a larger security breach. Yes, I know passwords are
easily broken as they are hashed and the Excel hashing is easy to break, but
at least it forced them to have to use something to break open the
passwords, but in this manner, they can just simply get around the password
via very minor VBA coding by using Workbooks.Open method on the file and
avoid the Auto_Open procedure all together, whereas if the Open Event on the
workbook object was working like it suppose to be, even if they use the
Workbooks.Open method to open the workbook, the codes in the Open Event of
the workbook object of the workbook being open would run automatically.

This is the main difference between the "Private Sub Auto_Open()" procedure
within a standard module not running automatically when the workbook is
opened via VBA, and the Open Event on the workbook object running
automatically when the workbook is opened via VBA. That is until the issue
of this Open Event not working at all in XL2002.

--

Sincerely,

Ronald R. Dodge, Jr.
Master MOUS 2000

"XP" <(E-Mail Removed)> wrote in message
news:7E45A9CD-C4EA-4AEC-B4C7-(E-Mail Removed)...
> Hi,
>
> I haven't had the issue of the auto open, but I do know you can by pass it
> by holding down the shift key if a file is opened normally.
>
> Do you know if that was just a bug in an earlier version of XL that has
> been
> fixed by now?
>
>
> "Ronald Dodge" wrote:
>
>> You could use the Terminate Event on the userform to unlock these things.
>> However, if you prefer, you can also setup an input box or have it go to
>> a
>> different user form for something like putting in a password to unlock
>> everything.
>>
>> I also had a similar type situation in June of 2001 when I built my
>> production reporting system for the operators to report into. I mainly
>> password protected the worksheets, workbook, and VBA, which then I used
>> code
>> to control a lot of the various things. Since I ran into issues of the
>> Open
>> Event on the Workbook object not working at times when the workbook is
>> opened like it suppose to regardless if it's opened by way of user
>> opening
>> or VBA opening. I ended up using the "Private Sub Auto_Open()" route to
>> run
>> code that needs to be done just after the file itself is open. Now with
>> this route, it runs automatically if user opens the workbook, but it
>> doesn't
>> run automatically if it's opened by VBA.
>>
>> I not only had to have it locked down so as operators couldn't just make
>> adjustments, but also had to have a way to make adjustments to the
>> various
>> individual files on an as needed basis. To this day, this reporting
>> system
>> that I built in June 2001 over a 3 week period is still in place.
>>
>> --
>>
>> Sincerely,
>>
>> Ronald R. Dodge, Jr.
>> Master MOUS 2000
>>
>> "XP" <(E-Mail Removed)> wrote in message
>> news:4239B8C2-7C97-4D07-BDB7-(E-Mail Removed)...
>> > Using Office 2003 and Windows XP;
>> >
>> > I am developing a form for wide distribution that will be locked down
>> > fairly
>> > well. I know anything can be hacked, the sole purpose is to discourage
>> > casual
>> > mistakes and tampering that would generally compromise the programming
>> > built
>> > into the form.
>> >
>> > However, I need to build myself a back door into the form that will
>> > unlock
>> > everything and restore certain menus that will be controlled, etc. This
>> > is
>> > needed so that myself and another developer can periodically perform
>> > maintenance on the form. I already have the unlocking code written, but
>> > what
>> > is a good way to access it without a user stumbling onto the key?
>> >
>> > Does anyone have any suggestions for how to "back door" my way into my
>> > own
>> > locked down form once its placed into production?
>> >
>> > All suggestions welcomed, please respond...thanks in advance.
>> >
>>
>>
>>