Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations wOOdy-Soft on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Password protect my Application 1
- Thread starter tforr
- Start date
Mike Lewis
Programmer
Tom,
Password-protecting your application will not prevent people from accessing your data from outside the application. The only way to do that is to encrypt the data. There are several threads and FAQs in the VFP-related forums that discuss the ways of doing that.
Mike
Mike Lewis
Edinburgh, Scotland
My Visual Foxpro web site: My Crystal Reports web site:
Password-protecting your application will not prevent people from accessing your data from outside the application. The only way to do that is to encrypt the data. There are several threads and FAQs in the VFP-related forums that discuss the ways of doing that.
Mike
Mike Lewis
Edinburgh, Scotland
My Visual Foxpro web site: My Crystal Reports web site:
-
1
- #3
Hi
There are many ways..
1. You can make the table extensions different from .DBF
That way, people will not know that they are VFP tables. WHen you open
USE myTable.FBD with extension for example will make you open. But this will protect only against accidetal opening by browing the tables. This will not safeguard against malicious openings of using the same syntax in command window.
2. Stop modifications... You can also allow the tables to be browsed and viewed. But you can protect it against editing, deleting and inserting new data by using triggers.
Make the tables part of a DBC. Then use insert triggers, delete triggers and update triggers.
In the trigger routine.. use the first command as..
IF VARTYPE(gcPass) = "U"
RETURN .f.
ELSE
IF !gcPass
RETURN .f.
ENDIF
ENDIF
where gcPass is a global variable specified in your main.prg and initialised as gcPass = .t.
The above code will avoid modifications to tables unless a gcPass=.t. is first created in the command window.
If you application returns to VFP6 command window, make sure you set that gcPass=.f. before returning, so that the variable is not set for direct use.
But as programmer, you know how to handle this from command window.
3. Yet another way to allow modifications but catch from errors...
Create a checksum field in all your tables and ensure that the update/insert routines write this field with correct vales.
SO you can just browse for unmatched records to know, that it is all direct insertions by culprits. If you do directly, you will know to set the checksum field correctly.
4. Encrypted field values is yet another way - more complicated, but more safer. But does not protect against modifications.
5. You can hide and unhide tables in single user applications (I would not recommend this approach, since as you grow to multiuser approach, that fails)
There copuld be more which may not come quick to my mind now.
____________________________________________
ramani - (Subramanian.G)
There are many ways..
1. You can make the table extensions different from .DBF
That way, people will not know that they are VFP tables. WHen you open
USE myTable.FBD with extension for example will make you open. But this will protect only against accidetal opening by browing the tables. This will not safeguard against malicious openings of using the same syntax in command window.
2. Stop modifications... You can also allow the tables to be browsed and viewed. But you can protect it against editing, deleting and inserting new data by using triggers.
Make the tables part of a DBC. Then use insert triggers, delete triggers and update triggers.
In the trigger routine.. use the first command as..
IF VARTYPE(gcPass) = "U"
RETURN .f.
ELSE
IF !gcPass
RETURN .f.
ENDIF
ENDIF
where gcPass is a global variable specified in your main.prg and initialised as gcPass = .t.
The above code will avoid modifications to tables unless a gcPass=.t. is first created in the command window.
If you application returns to VFP6 command window, make sure you set that gcPass=.f. before returning, so that the variable is not set for direct use.
But as programmer, you know how to handle this from command window.
3. Yet another way to allow modifications but catch from errors...
Create a checksum field in all your tables and ensure that the update/insert routines write this field with correct vales.
SO you can just browse for unmatched records to know, that it is all direct insertions by culprits. If you do directly, you will know to set the checksum field correctly.
4. Encrypted field values is yet another way - more complicated, but more safer. But does not protect against modifications.
5. You can hide and unhide tables in single user applications (I would not recommend this approach, since as you grow to multiuser approach, that fails)
There copuld be more which may not come quick to my mind now.
____________________________________________
ramani - (Subramanian.G)
Tom,
Just remember that short of encrypting the data, any determined user can use a Hex Data File Viewer and find all the data in any VFP table. If you really have security concerns, consider using SQL server (MSDE IS SQL server and free, but in some ways limited, but for a single user environment this wouldn't be a problem!).
Rick
Just remember that short of encrypting the data, any determined user can use a Hex Data File Viewer and find all the data in any VFP table. If you really have security concerns, consider using SQL server (MSDE IS SQL server and free, but in some ways limited, but for a single user environment this wouldn't be a problem!).
Rick
- Thread starter
- #5
Hi,
Thanks for all the replies. All I really need for the time being is to stop users from opening my application and therefore having access to the data there and then. I want to be able to password protect my app but really dont know where to start. I have a database and when I first open it I call a form which is my main menu. I can then go on to select what forms I want to open. I want the user to click on my executable and before they get the main menu, I want them to be asked to enter their username and password. How difficult would this be? (Any suggestions would be much appreciated) I cannot find any tutorials at all on the web or within my book on how to do this (Visual FoxPro 6.0 Enterprise Development).
Thanks for all the replies. All I really need for the time being is to stop users from opening my application and therefore having access to the data there and then. I want to be able to password protect my app but really dont know where to start. I have a database and when I first open it I call a form which is my main menu. I can then go on to select what forms I want to open. I want the user to click on my executable and before they get the main menu, I want them to be asked to enter their username and password. How difficult would this be? (Any suggestions would be much appreciated) I cannot find any tutorials at all on the web or within my book on how to do this (Visual FoxPro 6.0 Enterprise Development).
Password protecting access to users running your application is just like usage of many other Forms.
1. Early in your application execution you use a Form to allow the user to input Username and/or Password.
NOTE - To mask the password entry, you can use the Keyword Search to find "Password" where use of 'masking' fonts, etc. is mentioned.
2. You check the input values against pre-stored allowable combination values (may be stored encrypted or not) to see if you get a match or not.
If you get a match, then go on to the remainder of the application.
If not, you can loop with a down counter to allow a fixed number of multiple attempts or, alternatively, just display a message and throw them out (QUIT).
All in all, pretty basic.
Good Luck,
JRB-Bldr
1. Early in your application execution you use a Form to allow the user to input Username and/or Password.
NOTE - To mask the password entry, you can use the Keyword Search to find "Password" where use of 'masking' fonts, etc. is mentioned.
2. You check the input values against pre-stored allowable combination values (may be stored encrypted or not) to see if you get a match or not.
If you get a match, then go on to the remainder of the application.
If not, you can loop with a down counter to allow a fixed number of multiple attempts or, alternatively, just display a message and throw them out (QUIT).
All in all, pretty basic.
Good Luck,
JRB-Bldr
- Thread starter
- #7
- Thread starter
- #8
Hi again,
I have created a table within VFP 6.0 called login.dbf. Within this table I have created two fields. These are:
* userid (Character 10 and indexed)
* password (Character 10)
Once this table was created, I made a form and called it login.scx. On this form are two-text boxes. These are:
* txtUserName
* txtPassword
These is also a Close and Ok button. The state of the windows has been set to modal.
Within the click event on the Ok button I want to be able to validate the data within the login.dbf table so that if the data is valid, the login form will close and my main menu form will open. At the moment there is no login form, so when the user clicks of the exe they are taken directly to the main menu where they have access to all the data. Eventually I would like the Idea of having different user levels but I would like to understand this method first.
Can anyone help? If so then much appreciated.
Thanks and kind regards,
Tom.
I have created a table within VFP 6.0 called login.dbf. Within this table I have created two fields. These are:
* userid (Character 10 and indexed)
* password (Character 10)
Once this table was created, I made a form and called it login.scx. On this form are two-text boxes. These are:
* txtUserName
* txtPassword
These is also a Close and Ok button. The state of the windows has been set to modal.
Within the click event on the Ok button I want to be able to validate the data within the login.dbf table so that if the data is valid, the login form will close and my main menu form will open. At the moment there is no login form, so when the user clicks of the exe they are taken directly to the main menu where they have access to all the data. Eventually I would like the Idea of having different user levels but I would like to understand this method first.
Can anyone help? If so then much appreciated.
Thanks and kind regards,
Tom.
You can expand the properties (fields) in your login.dbf so that they will "tell" the program menu's, form's, etc. what is allowed and what is dis-allowed.
One possible way might be to create Groups for your Users such that a Group is allowed certain access rights, etc. The individual user's group is assigned when they are entered into the login.dbf.
If you have declared a UserGroup variable PUBLIC (or public by Scope) prior to login and then assign the user's group to it after successful login, then that Group variable can be used throughout the application to control access rights.
This basic approach can be magnified in complexity as much as you want so as to control access to individual menu pops, forms, etc.
Good Luck,
JRB-Bldr
One possible way might be to create Groups for your Users such that a Group is allowed certain access rights, etc. The individual user's group is assigned when they are entered into the login.dbf.
If you have declared a UserGroup variable PUBLIC (or public by Scope) prior to login and then assign the user's group to it after successful login, then that Group variable can be used throughout the application to control access rights.
This basic approach can be magnified in complexity as much as you want so as to control access to individual menu pops, forms, etc.
Good Luck,
JRB-Bldr
- Status
Similar threads
