Results 1 to 13 of 13
  1. #1
    Join Date
    Jun 2008
    Posts
    24

    Unanswered: very very stupid startup mistake?

    Ok please can i have the anwser to this with the smallest amount of teasing and poking fun at what a stupid and noob mistake i made.

    How do i resore the menu on startup which i disable in startup config.

  2. #2
    Join Date
    Feb 2004
    Location
    One Flump in One Place
    Posts
    14,912
    Just hold down shift as you double click the database\ shortcut to open it.

  3. #3
    Join Date
    Feb 2004
    Location
    Chicago, IL
    Posts
    1,312
    You haven't worked with Access if you haven't made this type of a mistake at least once. I can't even count the number of times I needed the Shift key to get me out of a problem.

  4. #4
    Join Date
    Dec 2002
    Location
    Préverenges, Switzerland
    Posts
    3,740
    browse the code-bank.
    somewhere there i dropped an outline demo of making different things happen in MDB, 1st use MDE, Nth use MDE.
    ...i haven't needed the shift-key since.

    izy
    currently using SS 2008R2

  5. #5
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    I use a different technique which keeps the users out of menu system (and tables) but lets me click a button to get to them.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  6. #6
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    Any hints as to which method that might be? ^^
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  7. #7
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    For me? The getuser permission example in the code bank. I use a MainFormBackground (maximized) and then popup/modal forms with a button to close that form (which checks to see if it's my loginiID) and the MainFormBackground. Using this technqiue the users can't get to any of the menu items or close any of the forms to get behind the scenes. When I click the close button, I have full access to all the menu items (but see the latest example here: http://www.dbforums.com/showpost.php...9&postcount=68 - I personally think it works pretty slick. But I made it so I have to like it.

    Any Feedback you can give me on it StarTrekker would be fantastic!
    Last edited by pkstormy; 06-11-08 at 00:55.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  8. #8
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    Thanks, I'll check it out and give some feedback when I get back home
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  9. #9
    Join Date
    Sep 2007
    Location
    Global Village
    Posts
    185
    I personaly disable menu and use code to disable Shift baypass as well, so whenever I need to open db with shift baypass I simply enter a password and it enable the Shift baypass again.
    see Code bank for Shift baypass enable/disable example code, but I hink this is depend to developer style to how secure his db.
    <<Never Walk on the Traveled Path, Because it only Leads you to where the Others have been.>>
    Graham Bell

  10. #10
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    Funky.

    Ok, here's your feedback PK.

    Pros
    * Fetching the username from windows is a nice way of bypassing the need for a secondary login within the application.
    * The systeminfo API stuff is great, it can be very helpful in things like error logs.


    Cons
    * If the network admins go and change people's usernames, the db is going to need an "upgrade".
    * This doesn't deal with shared computers - where multiple people share one computer and login yet need different security levels within one application. Nor does it deal with the quite likely possibility that the windows username is the same for multiple people.
    * The modal, popup, maximised form background eliminates the use of custom menus and custom toolbars.
    * There is a major security hole. All anyone needs to do is create a user in windows with the same name as that of an admin user in the DB, maybe CathyX or Paul Kohn. Log in with that windows user and then go into the db. Security breached. And it would take stuff all effort to do it.

    For now, I think I will stick to my secondary logins and Access Control Lists which determine which userlevels can access what
    Last edited by StarTrekker; 06-11-08 at 07:09.
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  11. #11
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    Hey StarTrekker,

    Thanks so much for the feedback. Out of courtesy I wanted to address the cons you wrote:

    * If the network admins go and change people's usernames, the db is going to need an "upgrade".
    - A lot more than just an upgrade would have to happen if they did this. If SQL Server where being used, all those login names would also need to be changed. If using any Access table to track login names, those would need to be changed also. I see your point here and other than making the user select their username each time they open the mdb (which I'm totally against), I don't see a way around this (is that what you mean by Secondary logins?). What do you mean by Access Control Lists? - I'd like to see this. The loginID is also stored in the table for data so all these would also need to be changed if changing username's is going to happen.

    * This doesn't deal with shared computers - where multiple people share one computer and login yet need different security levels within one application. Nor does it deal with the quite likely possibility that the windows username is the same for multiple people.
    - It could be. I've had cases where multiple users use the same username. But I try to encourage "Groups" of names instead of every user in 1 group. This works best for SQL Server which I mostly use. Still, the alternative is someone selecting their own username when the mdb opens. But having "Groups" of users (and users in that group) does work well - I just didn't carry this example to that extreme.

    * The modal, popup, maximised form background eliminates the use of custom menus and custom toolbars.
    - Yes - it's supposed to. Custom menu buttons are created on the forms. The goal is to NOT let the user have access to the menu bars but if need be, there is a way using this technique where they still can have access to the menu's (don't make the popup form modal). If this technique is used, the developer basically controls all movements to which forms are opened and what menus are accessed (if any - then they are custom made on the form itself.)

    * There is a major security hole. All anyone needs to do is create a user in windows with the same name as that of an admin user in the DB, maybe CathyX or Paul Kohn. Log in with that windows user and then go into the db. Security breached. And it would take stuff all effort to do it.
    - I have to ask if this couldn't easily be done for other mdb's or any other getting the user loginID routine? This isn't a security replacement. This example shows a way to make it somewhat secure for the "typical" user who isn't trying to hack into the mdb and doesn't address that the user is trying to mimick another admin windows user name to hack into the mdb. The getuser routine in this mdb is a lot more secure though than other methods of getting the user loginID name but again, it's not a security replacement such as using an Access security mdw file which you also can hack into via mimicking another windows user loginID.

    Keep in mind that the goal of this whole example is to show 2 things: 1. How to easily get the user Login name and return it to a form or table (without having a login screen). 2. Make a security "type" structure to control what buttons a user sees on the forms. And 3. Control blocking access to the Access menus (if that is the goal.) oh...and 4. Allow the developer easy access to the code without having to exit and get back into the mdb some other way (click a button and everything closes and the developer has access to the menus and everything else). Also keep in mind that an mde of this versus an mdb will be better. There are other ways of doing the same thing in which all your points above can also be applied. I have yet to find an Access mdb secure enough that the cons you've written wouldn't apply. For someone with your Access skills, breaking into this is fairly easy. But for a typical user, it should present a challenge and keep them from going into things they shouldn't be going into in an Access application. You and I have the advanced Access skills where I doubt there's an mdb out there which either one of us couldn't hack into some way or another.

    By the way, did you happen to get signed up on that FileCyb website for finding good software? I'll PM you with some more.

    Again, thank for the feedback. It's greatly appreciated that you took the time to write it.
    Last edited by pkstormy; 06-11-08 at 18:59.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  12. #12
    Join Date
    Nov 2007
    Location
    Adelaide, South Australia
    Posts
    4,049
    Hey PK

    Who would have thought this would turn into the great debate on login alternatives! ^.^

    - A lot more than just an upgrade would have to happen if they did this. If SQL Server where being used, all those login names would also need to be changed. If using any Access table to track login names, those would need to be changed also. I see your point here and other than making the user select their username each time they open the mdb (which I'm totally against), I don't see a way around this (is that what you mean by Secondary logins?). What do you mean by Access Control Lists? - I'd like to see this. The loginID is also stored in the table for data so all these would also need to be changed if changing username's is going to happen.
    I am totally against unexpected modifications being required to be made to my software. The computer system / SQL Server configs etc are all too often completely out of my hands, but I guarantee my software so secondary logins are fine by me. I also find that users don't mind it either.

    And yes, when the MDE opens, the user needs to select a username and enter a password. I call this a "secondary login". Each user has a user level. Each userlevel gets access to the security components as detailed in the Access Control List. At the end of the day, all I need to do is modify data in the ACL to change who can access what.

    - Yes - it's supposed to. Custom menu buttons are created on the forms. The goal is to NOT let the user have access to the menu bars but if need be, there is a way using this technique where they still can have access to the menu's (don't make the popup form modal). If this technique is used, the developer basically controls all movements to which forms are opened and what menus are accessed (if any - then they are custom made on the form itself.)
    Why do you not want the user to be able to get to the menus and toolbars? They are no security threat if you make custom ones and prevent toolbar customisations, which I find far easier and more professional looking than a bunch of buttons on a form.

    - I have to ask if this couldn't easily be done for other mdb's or any other getting the user loginID routine? This isn't a security replacement. This example shows a way to make it somewhat secure for the "typical" user who isn't trying to hack into the mdb and doesn't address that the user is trying to mimick another admin windows user name to hack into the mdb. The getuser routine in this mdb is a lot more secure though than other methods of getting the user loginID name but again, it's not a security replacement such as using an Access security mdw file which you also can hack into via mimicking another windows user loginID.
    If there is no need for security, why bother with any of it then? Why not just grant all users full access?

    With secondary logins, changing windows user logins won't make a difference.

    And it's often not the user trying to hack into the MDB, but the disgruntled office worker who's gonna get fired next week and he wants to get admin login access so he can wreak havoc.

    I don't use MDW logins either. I use a manually controlled login system. My own USERS table, my own ACL table etc.

    Keep in mind that the goal of this whole example is to show 2 things: 1. How to easily get the user Login name and return it to a form or table (without having a login screen).
    The GetUser function and others generatable from the SystemInfo class are very nice

    4. Allow the developer easy access to the code without having to exit and get back into the mdb some other way
    Definitely a nice benefit

    I have yet to find an Access mdb secure enough that the cons you've written wouldn't apply
    .
    You haven't seen my software then All of the issue I raised are addressed in my secondary login design. It's pretty damned secure when the tables are on SQL Server.

    For someone with your Access skills, breaking into this is fairly easy. But for a typical user, it should present a challenge and keep them from going into things they shouldn't be going into in an Access application. You and I have the advanced Access skills where I doubt there's an mdb out there which either one of us couldn't hack into some way or another.
    Agreed.... however, if the SQL Server passwords were kept from me, I can't even break into my own installed applications

    By the way, did you happen to get signed up on that FileCyb website for finding good software? I'll PM you with some more.
    I did, but haven't spent much time poking around there, I've been kinda busy, but thanks very much for the links, I'm bookmarking them all

    Again, thank for the feedback. It's greatly appreciated that you took the time to write it.
    You're very very welcome!
    Owner and Manager of
    CypherBYTE, Microsoft Access Development Specialists.
    Microsoft Access MCP.
    And all around nice guy!


    "Heck it's something understood by accountants ... so it can't be 'that' difficult..." -- Healdem
    "...teach a man to code and he'll be frustrated for life! " -- georgev

  13. #13
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926
    Thanks StarTrekker - you're a cool dude. When you get a chance, send me a copy of the security setup you have. I'd really like to take a look at it.
    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
  •