Password setup

[kevygee]

I'm creating a data access page that can be used over the internet to add information into the database. The database is password protected. The functionality currently is that when a user accesses the data access page, they need the database password in order to submit information. We don't have a small number of users and giving all these people the password to the database would comprimise the security of the system.

I am looking for a functionality such that the people that edit the database, either by the front end application or by opening the database directly to be password protected. But the data access page not to be.

Any ideas on how I can achieve this functionality?

 

[KeithIT]

Search for "password" and "security" on this forum. There are a lot of great posts on the subject. You can be more specific in your search if you find more information than you need.

 

[kevygee]

Thanks a lot for your speedy reply. I searched the forums for my problem yesterday, and I can't seem to find anything relating to data access pages specifically or even anyone who wanted to setup their database like I want to. I think what makes mine different is that I don't want to require a password for users to submit information, but in order to see the actual data I want to require a password. Trying to keep the data safe, but the front end easy to use.

Is there a way I might be able to replicate this functionality by maybe creating a user group that only has access to add new data but password is blank? Can that be done? Thoughts?

 

[The_Doc_Man]

I don't want to require a password for users to submit information, but in order to see the actual data I want to require a password.

Is this a "blind" submission? I.e. You don't have to see the contents of the DB to send something into it? That is what your words seem to say.

the people that edit the database, either by the front end application or by opening the database directly to be password protected. But the data access page not to be.

Perhaps as part of the DAP you can include an input box that asks for the required password, but only if you use a particular function (click on a particular button, perhaps). Any other time, you are just browsing.

When you submit a data entry, include the password that was provided in the input box. But don't store that password in the final record. Strip it by putting it into an intermediate table. Allow the updates to occur from the intermediate table but only for those records that have the correct password. And of course, the DAP will not "see" the intermediate table. It will only show the final table.

 

[The_Doc_Man]

Separate comments: You know your requirements so I will make no judgements here. Further, it is commonplace that web-based requirements differ from more traditional methods of input.

However, by making the requirement to allow no-password browsing, you pretty much put the kibosh on using workgroup security to do this. Workgroup security doesn't have a "no password unless you are entering data" mode. Among other things, if the user came in without a password but then decided to enter data anyway, it is already too late for the Workgroup to do much for you.

You also make it nearly impossible to use system login security to handle it, either. The same problem occurs. By the time your user decides to actually enter data, that user is already in the database.

That leaves you with the problem of "rolling your own" security.

The problem, of course, is that TECHNICALLY, web pages are not session-based for the most part. There is no guarantee of continuity. Each web-page activation is an independent event. If you want some web pages to require no password, you effectively require ALL pages to require no password - and that forces you to scramble for those cases when you DO require a password for data entry.

 

[kevygee]

Hmm, I don't think I quite understand what you're saying. Let me try to explain myself better.

In order to automate the a paperwork procedure, I want to setup a system that allows users to fill out a form online. The user group is a large number of people, changing often. When the user submits the form, the form needs to be processed and actions needed to be taken before the form can safely and officially be stored with past forms. So, to replicate this, I was going to have an extra field in the table that holds the form info, named "processed" and this would be either true or false. (False when it is initially submitted, set to true after the form has been processed). This would logically separate the two sets of forms.

Now, I have this form setup as a data access page so it can easily be used over the internet. The people who will be processing the submitted forms (admins) will have the password to access the database, but the people submitting the forms will not (users), and because of the large, changing group of users, I do not want them to have to put in a password. Instead, just go to the website, fill out a few necesarry fields and voila. They are done.

Therefore yes, this would be a "blind" submission. They only need to submit their own information and not see other's information.

 

[The_Doc_Man]

Clearer. Think of TWO database similar in structure. The DAP works off of the one used for blind submission. It has no workgroup security issues.

The "real" database can have workgroup security and can link to the submission table in the first database. Then you can have data entry or data approval forms in the real database, which can be password protected.

Does that idea help?

 

[kevygee]

Yes it does. That's a great idea, the only problem that I see would be the transfer of data between the two tables. For example, once the form is processed, it needs to be archived with the rest of the forms that have been processed, which would require moving the entry from a table in one database (submission table) to a table in the other database (secure database).

The only way I see doing this is by writing some VBA code that would transfer each field separately to a new entry in the database when an admin approves the form. Does this sound right? Can anyone think of a better way?

 

[cagmuer]

Look for this line in your DAP

<a:ConnectionString>Provider=Microsoft.Jet.OLEDB.4.0;User ID=User;Data Source=z:\Job Boxes.mdb;Mode=Share Deny None;Extended Properties=&quot;&quot;;Persist Security Info=True;Jet OLEDB:System database=z:\Security.mdw;Jet OLEDB:Registry Path=&quot;&quot;;Jet OLEDB:Database Password=readfiles;quot;&quot;;Jet OLEDB:Engine Type=0;Jet OLEDBatabase Locking Mode=1;Jet OLEDB:Global Partial Bulk Ops=2;Jet OLEDB:Global Bulk Transactions=1;Jet OLEDB:New Database Password=&quot;&quot;;Jet OLEDB:Create System Database=False;Jet OLEDB:Encrypt Database=False;Jet OLEDBon't Copy Locale on Compact=False;Jet OLEDB:Compact Without Replica Repair=False;Jet OLEDB:SFP=False</a:ConnectionString>

Using this, I think you are able to specify what the default user id and password the DAP will use and thesefor your users won't see the loggin