General

Re: Form protection

Patrick Halstead — Thu, 13 Apr 2006 04:48:11 GMT

Hi Mark,

How about using 2 forms and deriving the 2nd one from the 1st where the prepopulated data is set to read-only?

Scenario:
1. Corporate employee #1 fills out form A and clicks submit
2. Submit saves form A to the network drive, opens form B passing it a reference (refID) to form A (more on that below), and closes form A
3. Form B's OnLoad code detects initialization (refID not set), sets the refID, sends e-mail and closes.
4. Corp employee #2 receives e-mail and double clicks on form
5. Form B's OnLoad code sees that the refID is set and loads Form B into a secondary data source that is bound to the main view using read-only controls.
6. Corp employee #2 fills out the editable fields in the form and saves.
7. Form B saves to net drive. The only data that is saved by the employee is the data they entered and a refID to the pre-fill form.

Form A should call NewFromSolutionWithData and pass an XML to form B that contains the refID of the existing form. That means after it is submitted. This is not hard to do. Another approach to passing the refID is to open form B and set the form's values from form B - Greg has a HowTo on how to communicate between forms.

Limitations of this solution:
- Employees must be connected to corporate network for form B to load form A data and show to user.
- Corp employees filling out form A will see another form open and close - not an integrated UI experience.
- It is still possible for corp employee 2 to manually modify the refID, but that will change all of the pre-fill data and not just one field. In addition, the bar is raised since they have to figure out the refID and manually edit in Notepad. You could further obfuscate using a GUID (global unique identifier) which is even harder for humans to deal with since it's 16 characters. If you absolutely must protect, you could digitally sign a section containing just this refID and that would protect it.

There are other options, but this is my idea for tonight.

Re: Form protection

Mark Slominski — Wed, 12 Apr 2006 13:35:02 GMT

Patrick: Here is what we are trying to accomplish. Pretty basic, what would be the easiest method? We are going to have a form available to our corporate employee's on a network drive. We want them to fill out the form and email it to another corporate employee. The information on the form will only be used to 'setup' that employee in an application. So our goal is when the employee fills out the form, that the information can't be changed after the form/email has been sent.

Re: Form protection

Mark Slominski — Mon, 10 Apr 2006 17:25:47 GMT

Patrick: Thanks for the response. Unfortunately I have only taken Infopath 101. I will try to decifer your solutions and see if I can apply them. Thanks

Re: Form protection

Mark Slominski — Mon, 10 Apr 2006 17:20:42 GMT

quote:
Originally posted by Patrick Halstead

Hi Mark and welcome to our forum,

If the form is saved to SharePoint via the out-of-box submit to SharePoint data adapter then it is possible for someoone to save the file to their desktop (from SharePoint) and edit the XML file in notepad to change the data.

There are several ways to get around this. First, you can use digital signatures - we have done this for several projects that had audit-tracking requirements. Another option is to submit the forms to a database (through a Web service like our Database Accelerator product) and either a) turn on auditing in the database (to save all versions), or b) control access to the form based on the state of the workflow. Another way to prevent edits is to implement some encryption in the form that stores the main data source in a base 64 blob and on load decodes it into a secondary DOM which is bound to the view. Or just use the main DOM and an ID to get the data on load from a Web service that controls access to it. Many different techniques...

It really depends on the access control for the forms at their destination. In general, this isn't a big issue though since there are a variety of solutions

Re: Form protection

Patrick Halstead — Sat, 08 Apr 2006 06:59:37 GMT

Hi Mark and welcome to our forum,

If the form is saved to SharePoint via the out-of-box submit to SharePoint data adapter then it is possible for someoone to save the file to their desktop (from SharePoint) and edit the XML file in notepad to change the data.

There are several ways to get around this. First, you can use digital signatures - we have done this for several projects that had audit-tracking requirements. Another option is to submit the forms to a database (through a Web service like our Database Accelerator product) and either a) turn on auditing in the database (to save all versions), or b) control access to the form based on the state of the workflow. Another way to prevent edits is to implement some encryption in the form that stores the main data source in a base 64 blob and on load decodes it into a secondary DOM which is bound to the view. Or just use the main DOM and an ID to get the data on load from a Web service that controls access to it. Many different techniques...

It really depends on the access control for the forms at their destination. In general, this isn't a big issue though since there are a variety of solutions

Form protection

Mark Slominski — Fri, 07 Apr 2006 19:55:36 GMT

We are in the early phases of determining if we are going to use Infopath at our company. Can someone help with our question or point me in the right direction to find the solution? We have a question concerning the protection of the data in the fields after the initial form has been filled out. Once the form has been filled out then sent to the required destination, can that form (all enterable fields) be protected from further changes?