Welcome To The Home Of The Visual FoxPro Experts  
home. signup. forum. archives. search. google. articles. downloads. faq. members. weblogs. sponsors. rss.
 From: Ken Murphy
  Where is Ken Murphy?
 Springhill
 Canada
 Ken Murphy
 To: KASSEM NASSER
  Where is KASSEM NASSER?
 JEDDAH
 Saudi Arabia
 KASSEM NASSER
 Tags
Subject: RE: Password Protection
Thread ID: 160680 Message ID: 160842 # Views: 96 # Ratings: 3
Version: Visual FoxPro 9 Category: Security and Application Protection
Date: Sunday, February 17, 2008 7:11:48 PM         
   


> Thanks a lot Ken. I am using the passwords coz every user may have differnrt rights, like some reports will be granted to him other no or he may add a transaction but not delete. Also there are rights per module like one user can work Acconts but not Stock and so on. Thats why i am using Windows user name otherwise i will have so many users on window level. another reason is some times i have small programs to do certain modifications on the data which i prevent others from using it by having a password.
>
> I searched in google regarding passwords, there are many "*" passwords reveals which i think what this guy is using.

Kassem,

You can still use windows security. Lets take the example of an accounting application. In a typical VFP app, you would have one EXE that allows the user to access any section of the accounting application. You don't want everybody to have access to the payroll section of your app, so you need to block unauthorised users from accessing that menu item. You create a permissions table and you use a function in the Payroll menu item's "Skip For:"

* Skip For NOT PayrollPermission()

FUNCTION PayrollPermission
LPARAMETERS tcUserName
SELECT * FROM MyPermissionsTable ;
   WHERE cModule = "Payroll" AND ;
         cUserName = tcUserName ;
   INTO CURSOR csrTemp
IF _TALLY > 0
   && Found a payroll permissions record so return the lPermission field
   && If the user has permission this field will be .t. otherwise it will
   && be .f.
   RETURN csrTemp.lPermission
ELSE
   && No payroll permissions record so deny entry
   RETURN .f.
ENDIF


I assume that you are already running something like this. Unfortunately, you have to develop a permissions table and a utility that your SysAdmin can use to grant permissions. Again, your SysAdmin wants to use Active Directory to grant permissions - he/she does not want or need yet another permissions utility that he/she needs to learn how to run.

You can still use Windows Permissions here. You need to remember that in Windows, you grant permissions to files and folders. You cannot grant permissons to modules if all of the modules are contained in a single EXE. The question then becomes "must I use a single EXE file?" Why not use a number of EXE files. Lets go back to that accounting example. We only want Payroll Department users to be allowed to access the Payroll module. OK, we create a PayrollUsers user group, and add the payroll department users to that group. We then separate out the payroll module from your EXE. (Indeed you would seperate out all of the modules - each one gets it's own EXE. You would have an Inventory.Exe an AccountsReceivable.EXE, and AccountsPayable.Exe, etc.) Now you can grant your PayrollUsers group read/execute permissions to that Payroll.EXE file. Only members of that PayrollUsers group will be able to see the Payroll.EXE file, let alone run it.

OK, you say that you already have this massive application and it sounds as if it would be a lot of work to make these modifications. Actually, it isn't any work at all. In fact, it will result in less work for you. Think about it - you have all of your accounting modules broken out into separate EXE files and each of these modules can be run from the Windows Start Menu (assuming that you have the correct permissions.) This means that you no longer need to maintain a Main Menu. You would be using Windows permissions, so you don't need to maintain a permissions table, nor do you need to create and maintain a form for granting those permissions. All you really need to do is create a series of new projects (one for each module.) This is actually simpler than it looks. Take your existing Main.Prg and make a copy for each new module. (For example copy it to PayrollMain.prg.) Now go in and delete the DO MyMainMenu.mpr line and instead, call your main form for that module with a DO FORM MyMainForm. Now create a new project called Payroll, add that PayrollMain.Prg to the project and set it as main. Build the project and compile it into an EXE. Quite simple.

Here are the benefits:

1 - Your SysAdmins still gets to use ActiveDirectory (less work for him/her)
2 - You do not need to maintain a permissions table or form (less work for you)
3 - You do not need to maintain a main menu - you can use the Windows Start menu instead (less work for you)
4 - Conversion is quite simple - basically all you need to do is create a few new Main.prg files (one for each module) and you can use your existing Main.prg as a basis. Next, create a new project for each module, add that module's main.prg, and build it. The remainder of the work is done by your SysAdmin - setting up user groups and setting permissions.


Ken
You shall know the truth - and the truth shall set you free. (John 8:33)



COMPLETE THREAD
Password Protection Posted by KASSEM NASSER @ 2/15/2008 9:00:31 PM
RE: Password Protection Posted by Borislav Borissov @ 2/15/2008 9:05:40 PM
RE: Password Protection Posted by KASSEM NASSER @ 2/15/2008 9:14:42 PM
RE: Password Protection Posted by Borislav Borissov @ 2/15/2008 9:20:16 PM
RE: Password Protection Posted by Barbara Peisch @ 2/15/2008 9:23:51 PM
RE: Password Protection Posted by Jun Tangunan @ 2/23/2008 6:13:24 AM
RE: Password Protection Posted by Ken Murphy @ 2/15/2008 10:34:22 PM
RE: Password Protection Posted by Craig Boyd @ 2/16/2008 12:29:08 PM
RE: Password Protection Posted by Ken Murphy @ 2/16/2008 1:14:05 PM
RE: Password Protection Posted by Jim Booth @ 2/17/2008 6:41:47 AM
RE: Password Protection Posted by Ken Murphy @ 2/17/2008 12:35:03 PM
RE: Password Protection Posted by KASSEM NASSER @ 2/17/2008 5:31:45 PM
RE: Password Protection Posted by Ken Murphy @ 2/17/2008 7:11:48 PM
RE: Password Protection Posted by KASSEM NASSER @ 2/22/2008 12:24:58 AM
RE: Password Protection Posted by Joseph Agarpao @ 2/18/2008 2:39:13 AM
RE: Password Protection Posted by Ken Murphy @ 2/18/2008 11:32:30 AM
RE: Password Protection Posted by suhas hegde @ 2/18/2008 9:23:30 AM
RE: Password Protection Posted by Ken Murphy @ 2/18/2008 11:35:35 AM
RE: Password Protection Posted by suhas hegde @ 2/18/2008 5:58:48 PM
RE: Password Protection Posted by Ken Murphy @ 2/18/2008 8:38:41 PM
RE: Password Protection Posted by Ken Murphy @ 2/29/2008 2:08:54 AM
RE: Password Protection Posted by Hugo Ranea @ 2/16/2008 2:22:21 AM
RE: Password Protection Posted by suhas hegde @ 2/18/2008 9:19:47 AM
RE: Password Protection Posted by KASSEM NASSER @ 2/22/2008 12:30:43 AM
RE: Password Protection Posted by Tom Saddul @ 2/29/2008 7:21:20 PM
RE: Password Protection Posted by suhas hegde @ 3/1/2008 6:17:32 AM
RE: Password Protection Posted by Catalin Banici @ 3/4/2008 10:11:07 PM
RE: Password Protection Posted by Biju Thomas @ 3/8/2008 1:55:45 PM
RE: Password Protection Posted by Ken Murphy @ 3/8/2008 2:03:30 PM
RE: Password Protection Posted by Biju Thomas @ 3/8/2008 2:24:23 PM
RE: Password Protection Posted by Ken Murphy @ 3/9/2008 1:29:39 AM
RE: Password Protection Posted by Biju Thomas @ 3/9/2008 4:43:48 AM