Preventing users from disabling events

[bill]

Suppose you drive a workbook based on events like
WORKBOOK_CHANGE.

Suppose futher that the workbook is locked to prevent users from viewing the VBA.

But suppose a user enters the VBA EDITOR and in the IMMEDIATE WINDOWS, executes:

Application.EnableEvents = False

All of your hard event driven code now fails...

How do you prevent users from performing the above? I guess that means, preventing users from kicking off their macros when your workbook is open OR preventing users from access to the VBE when your workbook is open.

But also that means disabling any add-ins that turn off event handling as well...

Perhaps you can capture the events state change and if 'not authorized', disable the attempt?

Thoughts?

 

[Gates Is Antichrist]

A little tale of perspective:

tushar, being vastly, vastly experienced, instantly saw that the idea was fundamentally unallowable, and as such responded as though to scoff at the very thought of it.

I didn't initially see that. Perhaps neither did O.P. I looked at the idea at face value in a vaccuum, and pondered its viability. So I suspect there was a rift in perspective here.

Then it hit me. One of the most basic, fundamental user protections is that prompt "this workbook contains macros." Oh yeah - Duh! Of course - the user has the God-given right to rufuse service to anyone wearing a macro.

So the idea that O.P. started with was tantamount to forcing users to use macros. And we know that that just isn't allowed. When "machine takeover" or such was said, it was just an emphatically expressed extension of the unnacceptability of forcing code execution on unwilling recipients, I believe.

Like I said, it took me a while to see the obvious. If I had an idea, and someone sounded like they scoffed at it - due to conditions obvious to the objecter, but that sailed by my head ... and believing myself to be innocent - hell, I'd be indignant

 

[bill]

The idea is NOT a bad one and in fact can strengthen the perception of Excel in the eyes of the decision makes since this type of thinking makes the environment more secure.

By the way, business user have little to no rights on the corporate desktop and per my original reponse, considering them TO have some sort of abilty to deny the running of corporate sponsored code on their machine is counterintuitive.

And in fact the business has workbooks in play that will not allow users to interact with them unless the users DO allow macros to be run.

Nothing sailed over my head... I simply don't want this a thread to be about morals or ethics.

 

[Gates Is Antichrist]

Good points, Bill, but users get to prevent code from running. It's fundamental. Keep up the open mind though! Someone needs to! Don't expect that Microsoft will!

 

[bill]

No, users DON'T have that option, in the workplace anyway.
They will do what management tells them to do.

I have an open mind and I'll be damned if anyone 'tells' me how to keep shop at home.

But here at work, where security (next to safety) is a critical, paramount issue, anything that can be done to make the envirnmoent MORE securure will be done, provided management signs on.

 

[Smitty]

Suppose you drive a workbook based on events like
WORKBOOK_CHANGE.

Suppose futher that the workbook is locked to prevent users from viewing the VBA.

But suppose a user enters the VBA EDITOR and in the IMMEDIATE WINDOWS, executes:

Application.EnableEvents = False

All of your hard event driven code now fails...

How do you prevent users from performing the above? I guess that means, preventing users from kicking off their macros when your workbook is open OR preventing users from access to the VBE when your workbook is open.

But also that means disabling any add-ins that turn off event handling as well...

Perhaps you can capture the events state change and if 'not authorized', disable the attempt?

Thoughts?

Yes, find dumber users.

Not really concerned regards how hostile the technique is preceived nor do I believe that I'm advocating the 'takeover' of a users machine. Rather, I'm charged with delivering an airtight, production quality workbook for my firm.

Then please don't promise that you can do it in Excel, because frankly, you can't. And I hate the latter word.

Seriously, if you have you have users that advanced then the last thing you need to do is try to make Excel secure, which it ain't.

If you're shopping this to external customers, then look at a EULA. That's more secure then Excel, which has never been marketed that way.

Smitty

But with perhaps the right API calls, or perhaps with a COM addin, I suppose it is possible.

Like it or nor, Tushar wrote a lot of that book.

 

[Tom Urtis]

But suppose a user enters the VBA EDITOR and in the IMMEDIATE WINDOWS, executes:

Application.EnableEvents = False

All of your hard event driven code now fails...

Thoughts?

Actually in my opinion this is a very good question from a developers standpoint, to protect the integrity of a project's event-driven code while the subject workbook is open.

There are no guarantees, but just thinking out loud based on the Immediate Window scenario per your above quote which is an interesting event code circumvention avenue as you point out, if that is your primary concern, would it help if access to the VBE was made really difficult (not saying impossible here on purpose because Excel is not nor purported by MSFT to be a secure platform).

There are many ways to get into the VBE and Ivan Moala posted the code in this thread that addresses each way, which you can use in your open and close events to disable and re-enable the accesses to the VBE.

http://www.mrexcel.com/board2/viewtopic.php?t=24882

Note, its success depends in part on the local user's machine having allowed trusted access to the VBE. For that, see this code I posted which spells out for the user how to set the trusted access, which you can utilize to conditionally allow the workbook to open and then execute the disable procedure.

http://www.mrexcel.com/board2/viewtopic.php?t=177782

Of course, be sure to re-enable the VBE at Close.

If you have a requirement to do more than just temporarily restricting access to the VBE, which in and of itself for this narrow application and viable solution is not an unethical act, consider what those further restrictions would be, just in case you may (however unwittingly or well intentioned) be heading in a direction that could be detrimental to other end users' computers.