Results 1 to 5 of 5
  1. #1
    Join Date
    Sep 2008
    Location
    NM, USA
    Posts
    97

    Question Unanswered: The best way to go...

    Well, I've gotten all the forms and all the code and queries and everything in this project working just the way I want them to (thanks to everyone who's offered help so far!)

    Now I am faced with another aspect of developing this application... the user log on stuff. I kinda have an idea of where I'm going with this... basically I make a table to hold the user names and pass words with an auto-number primary key, and make a table of user roles with an auto-number primary key... and a table of user keys associated to role keys.

    Now the question is... How am I going to designate access privileges here? I was thinking of designating the role key from the login form to two global variables and have code in the form load events to check to see if this user role has access.

    Does this sound like a good way to go about this? Or is there some more practical way of doing it?
    "Unix is user friendly... It's just very picky about its friends."

    The best things in life...are well-documented.

  2. #2
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Hi

    (bare in mind I've not played a part in the development of your database so might be off track here)
    A few things:
    Is this security intended to be water tight? Resistant to malicious attacks? Resistant to someone copying files from the filesystem and removing from your employer's premises? Resistant to the curious & tech savy?

    The variable idea in iteslf sounds ok. I would, however, wrap access to it (no need for two once authenticated) in a function. If there is a crash, variables are wiped so you will always need to check that the variable contains a value and lookup from the table again if not. Also, your variable will need to be an array since you have a one to many relationship between users and roles.
    Personally, I would probably have a further many to many relationship from roles to permissions, and examine the permissions in your code.
    Testimonial:
    pootle flump
    ur codings are working excelent.

  3. #3
    Join Date
    Sep 2008
    Location
    NM, USA
    Posts
    97

    Wink

    Quote Originally Posted by pootle flump
    Hi

    (bare in mind I've not played a part in the development of your database so might be off track here)
    A few things:
    Is this security intended to be water tight? Resistant to malicious attacks? Resistant to someone coping files from the filesystem and removing from your employer's premises? Resistant to the curious & tech savy
    well, this is a fairly small, modest db project. there are only going to be maybe a handful of users, and it's only going to be accessible on our local network within the office.

    I pretty much want it to be resistant to like... people making changes to the data that shouldn't be...

    I'm very very green to the whole database design and implementation and all that... so i'm just trying to keep this as simple as possible for the moment.. ^_^;
    "Unix is user friendly... It's just very picky about its friends."

    The best things in life...are well-documented.

  4. #4
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Quote Originally Posted by atsukoarai86
    I pretty much want it to be resistant to like... people making changes to the data that shouldn't be...
    Well the questions I ask relate to this. "Security" is such a broad term. It can range from meeting regulatory & legal requirements to making it inconvenient for people to access tables directly. Only you know your needs. Personally, I don't treat security like your standard risk assessment. Imagine the worst case scenario you can live with. If a committed attacker steals, deletes, b0rks the data - can you (and more importantly your employers) live with that? If the answer is "no" then I prefer to not even consider probability (as you would normally when assessing risk). If the answer is yes, keep going until you find a business security need.

    So - what's your call? We can help once we know your parameters.
    Testimonial:
    pootle flump
    ur codings are working excelent.

  5. #5
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    Take a look at this example and how it does security (automatically retrieving the user's login ID and checking the security level):

    http://www.dbforums.com/showpost.php...9&postcount=68

    Notice also the table structure in the example. You could ideally put in any other security type values you wanted and created other levels. And notice also on the form how it makes buttons invisible, disabled based on the user's security level (calling a "retSecurityLevel(getUser) as boolean" function in the "Security" module to do it). This is just an example to be expanded upon but there are many different ways to do this. This is only what I've found to be easiest.

    As far as making it water tight though, we'll if any user knows the "hold the shift key down while opening the mdb/mde" trick, they can bypass the code. There is some disable shift key code in the code bank but the way I look at it is, if a user does this, they are "KNOWINGLY" bypassing the code to enter their data. Using the disable shift key code though just makes it more difficult for me to get into the mdb and code (which I'm doing throughout the day.) I can also usually find out who it is sooner or later (I have many different ways), and then I have a little chat with them (it's usually due to an error in the interface and they wanted to enter their data.) But I've encountered this maybe a couple of times over 20 years. Most general users don't know the shift key trick. Another more of a "water tight" type security for MSAccess is using MSAccess security itself. I will do this on critical hospital and City type mdb's where they want that extra embedded security, including the ability to assign who can/cannot make design changes to the forms/tables, etc..

    Normally though, I just use the same techniques as those found in the example (notice that you can't utilize any of the MSAccess menus in the example or close or get out behind the scenes - you "must" click the "close" button on the form (which then checks your security) to close the form and get behind the scenes.) It's a quick and easy technique using the example way without a lot of hassle for me to get in and make coding changes (or even show a user how to make the change.)
    Last edited by pkstormy; 10-18-08 at 02:35.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •