Binary Flags to track User Rights

[zmbd]

For establishing user "rights" in the past, I've use a ton of different methods: user security model, tables and related tables, and so forth

The ms access user-level security had the advantage that the user couldn't just easily bypass things and elevate privilege. To do so took some effort and some extra-know-how to get around the workgroup restrictions. I do miss that in some ways; however, it was a pain to maintain.

However, using the table/table-related_table methods I've had users find the table(s) (even the hidden/system tables!) and find a way to alter the user table so that they would have the desired role and then alter it back once done.

However, this time I was thinking about using Binary Flags to check for "rights." This is something I used to use in other codes a lot (especially back in the old CBM-Vic20 and machine level code – 5K was a lot of memory back then!); however, I've not used the method in VBA or a database.
I was considering that a 8-Bit set of flags would work just fine and I could store just the one number with the employee's information and get rid of one table and the associated look-ups, codes and the like. Maybe create one class module to pull the current windows user from advapi32.dll and then set the flags and allow admins to alter user’s rights by tweaking which flags were set. To make things fun, I would really only need 5 of the 8 bits, I could use the unused bits to mess with what values correspond to what rights.... say, as far as user rights would be concerned: 00011011 would be the same as 10011011 as well as =01011011 because I wouldn't be checking the first three (left to right) unused bits and it'd make the users scratch their heads. – Perhaps use a SHA digest to validate… or maybe use the “rights” as a password against their password. I was already considering using a SHA digest to store the user names…

or am I over thinking things?

[NeoPa]

Using bit-flags within a numeric (or even character/string) variable can certainly work. It makes sense to store such binary options that way (Various items within Access use a similar approach). What I'm really not getting here is what the question is supposed to be?

[zmbd]

I guess the question comes down to is this a reasonable method or is there a better way?

In this case, I'm actually going to use the bits to set the form's "allow... edit/addition/etc..." properties based on a few things.

[NeoPa]

It's a good way to store such information. That's a general comment. We still have little information as to exactly what is being stored, but I would hazard that this approach is sensible.

I would point out that checking such flags is somewhat clumsy in all languages, but especially so in VBA. You may want to provide routines (maybe even a class) to allow saving and querying such data.

Ultimately, only a good understanding of exactly how you expect to be using this can tell you whether it makes sense for you. Now everything has so much more in the way of resources the need to compact memory usage is much much less than it was. What works for you is hard for anyone else to say easily, but it would certainly be a way to obfuscate your settings - especially if you used five bit-flags and stored the result within an ASCII character for instance. A class could ensure that the three MSBs of the byte were set most appropriately for the value of the five LSBs.

[zmbd]

Ah... finally a moment to address this:

I would point out that checking such flags is somewhat clumsy in all languages, but especially so in VBA.

Yes. The class module was where I was going with this as I had/have (if I can find it again) some example code that I've planed to base the setting/retrieval.

Ultimately, only a good understanding of exactly how you expect to be using this can tell you whether it makes sense for you.

So my thoughts, a flag(s) to set the user level, and flags to set edit/add/delete.
I may also use the Tag property to store some information such as the user level that can open and then what right are available at the form level.

Say I want a form to open only for DBA and Supervisor; however, I only want read, no add, or edit (say it's an audit log) So the form will have the flags set for the two user levels and the then the remaining flags cleared. The user's flag set for their user level and then general rights...

One of the issues I've ran into is the cascading combo boxes within a single form. I like to use the header/footer section of the form for the CBOs and then build my filters against the bound form; therefore, the edit property has to be set to true and I have to trap the beforeupdate event and check for user rights. Guess could get around this with the form/subform wherein the parent allows the edit to be true and the subform has edit set to false - but I think I would loose the ease of two/multi stage filter (I have three CBO in one form to help with reports - thus the user can have a full report on the unfiltered (yuck) the first level... down to reports on specific type of product, as the records filter after each CBO is set.)

As I said, it's a work in progress. I do like the single ASCII thought...

[NeoPa]

I don't believe I would consider using such an approach unless I were needing to obfuscate the data myself. It's possible, but I believe even a class implemented routine would be easier and more efficient (that bit probably miniscule/unimportant) if done using discrete memory locations (or variables if you prefer).

That said, there's no reason not to take that route if you like the idea.

[zmbd]

And there you have it.

My goal was to make things a tad easier for me and more difficult for the user to elevate privlages.

In the past I've used a varity tables and forms approach... none of these really very, well, satisfying in impelementation and worse, because some users have that special little humph, they've been able to get at the tables either adding or changing the form name to their account or elevate their user status. Very Annoying. However, when the front end is set to MDE (or now ACCDE) altering the forms isn't a possiblity and with flags idea I thought a simple flaging scheme might work. Even if I used a decimal/hex numeric... each supervisor would could a different numeric and yet have the same user rights and I could set something within the forms themselves.

Just can't seem to figure out the right solution to the user rights - I work with too many people that are too smart for their own good.
:-)

[NeoPa]

Ah, Clearly the obfuscation is a real issue for you. Go for the bit flags. No question.

If obfuscation is a very important issue then you could also use reversible encryption. Unfortunately, clever users could simply take the value stored against a know admin/super user and apply it to their own record. I can't think of a better approach off hand though. Certainly, it would make fiddling with the data orders of magnitude more complex.