Microsoft InfoPath 2010
The official blog of the Microsoft InfoPath team
Common Tasks
recent posts
Tags
General
Office Blogs
Archives
Archives

September, 2006

MSDN Blogs > Microsoft InfoPath 2010 > September, 2006
Sort by: Most Recent | Most Views | Most Comments
Excerpt View | Full Post View
  • Microsoft InfoPath 2010

    Protecting Sensitive Data

    Posted over 7 years ago
    by
    • 9 Comments
    Frequently, we find developers using InfoPath as a platform for developing solutions that manipulate sensitive data, may it be financial data, patient records, or performance review forms. This article shares tips on protecting such data.
     
    First and foremost, you must know that an InfoPath form is a plain-text XML file. A malicious user can read it through Notepad or other text editor, circumventing any InfoPath authentication logic. So if a user has read access to an InfoPath XML form, anything stored in that XML file can be read. Information Rights Management in InfoPath 2007 allows storing encrypted XML; we'll talk more about it below.
     
    Also remember that an InfoPath form template (.xsn file) is just a CAB archive, containing plain-text files. These files store all client-side form logic. Information Rights Management allows you to encrypt form templates in InfoPath 2007, see more about it below.
     
    Like with any other client-server application development platform, you can never trust the logic that happens on the client. InfoPath uses the form template to store all form logic; if the user has access to the form template (and they must in order to be able to open any form based on that form template), they can create a hacked version of the template, circumventing any restrictions that the original form author put in place.
     
    This means that authentication and authorization performed on the client can't be trusted; calculations and data validation have to be re-done on the server. Here is an example of how this strategy can be realized for a simple record-keeping application:
     
    • Do not store sensitive data in the XML file; instead, store keys in the XML file, and perform queries on load that populate the rest of the data by using a database/web service. If the user is unauthorized (as determined by the server-side logic), return an empty dataset. You can even detect such condition on the client and show a friendly error message.
    • On submit, send the data to a web service and redo all non-schema validations on the server side. For example, if employees should not be able to submit expense reports above $100 without specifying an approver, have your web service process the dataset and verify that this condition is satisfied. 
     
    It is always a good idea to restrict access to a production form template by assigning read-only permissions to form users, write access to form maintenance staff, and no access to everyone else. This can be done by using permission features of the SharePoint Server or file shares. Even if you install form templates to the users' machines via a logon script, you can still control access to the .xsn file - provided the user is not running as an administrator, you can set their access to the template file to read-only.
     
    You may want to enable the protection feature for production form templates:
     
     
    However, remember that this protection feature is for recommendations only, it is not intended as a security mechanism. This will show the user a nice error message if they accidentally try to open the template in the Design mode, but won't defend the form template against a malicious user.
     
    Information Rights Management, or IRM, is a new feature for InfoPath 2007; some of you may already be familiar with the concepts from the other apps in the Office 2003 release. IRM allows the form author to protect both the form template and forms based on the template; IRM infrastructure must be in place in the organization to make this possible. Briefly, IRM is a way to encrypt both form templates and forms, allowing form author to specify who can access the template and suggest default rights for forms based on the template:
     
     
    Note that IRM is an InfoPath client-only feature, and it will not work in browser-enabled form templates.
     
    Alex Weinstein
    Program Manager
  • Microsoft InfoPath 2010

    Dynamic Pictures

    Posted over 7 years ago
    by
    • 6 Comments
    When designing a feature-rich InfoPath form template, it is sometimes necessary to provide a dynamic image in response to user action. InfoPath picture control hides treasures that will help you satisfy such a requirement. In this article, we will explore a technique that allows you to make this happen without writing any code.
     
    Here is our scenario: build a hardware order form for the telecommunications department. In the form, we would like to let the user choose the phone that they want to order, and show them a picture of the phone as soon as they select it.
     
     
    The following steps will make this possible:
     
    1. Place pictures of available phones in a shared location; let's call it http://mysite/phones/photos/. Pictures are named according to phone ID's - for example, 1.jpg, 2.jpg, 3.jpg, etc.

    2. Insert a picture control. When you do so, InfoPath will ask whether you want the picture to be included into the form, or if you want it to be linked. Choose the second option.
    3. Take a look at the node that was just inserted into your data source by going to View | Data Source. Let’s call the new node hyperlinkDataSource; it’s a node with data type "hyperlink".

    4. Insert a text box that’s also bound to hyperlinkDataSource.

    5. Preview the form. Use the picture control to attach the image. Observe how the path in the text box changes to reflect the path of the image you just attached. Try changing the value of the text box to point to a different picture. Note how the picture control displays the new picture when you tab out of the text box.

      Now, we want this step to happen programmatically, when the user selects the phone from the dropdown of available phones.

    6. Create a phone picker dropdown; labels in the dropdown will show phone names, and values will contain phone ID's that correspond to file names we used in step 1. The simplest way to do this is to enter the items manually; don't forget to include the default "pick a phone" item.




    If you want to get fancy, you can use a secondary data source - web service - to provide the list of available phones.

    1. Create a rule on the phonePicker node: set the value of hyperlinkDataSource to

      concat("http://mysites/phones/photos/", phonePicker, ".jpg")

    2. Go to control properties for the new picture control; uncheck the “Allow users to browse for new pictures” property.

    We're done! Preview the form and try selecting a few phones from the dropdown.
     
    Picture control is available in both InfoPath 2003 and 2007, however it is not supported in browser-enabled form templates.
     
    Alex Weinstein
    Program Manager
  • Microsoft InfoPath 2010

    Save the Date! Using Horizontal Repeating Sections

    Posted over 7 years ago
    by
    • 4 Comments
    InfoPath 2007 introduces a new flavor of the repeating section control - horizontal repeating section. It is useful when you want to present or edit repeating data in a structured format. When new items are added, they show up side-by-side with the existing items instead of one on top of the other.
     
    Horizontal repeating section is a new building block for layouts. In my previous post about horizontal repeating tables, we discussed how a horizontal repeating table is a combination of a horizontal repeating section and layout tables. You can make your own new layouts by using this new control.
     
    For example, one cool use of a horizontal repeating section is a "calendar" - style form:
     
    Play with it!
    Download the form template and try a few things (requires InfoPath 2007, and save it to your computer before opening it):
    1. Switch to a different month by using a dropdown on top of the form.
    2. Add a note for a day.
    3. Add a note with an exclamation sign (i.e. "presentation!") - notice the day turning red.
    4. Switch views to the summary view, and observe all appointments as a flat list.
    5. Open the form template in design view, and view its logic by going to Tools | Logic Inspector.
     
    How it's done
    In this form, each day in the calendar is displayed by using a horizontal repeating section; only the header ("Monday, Tuesday, Wednesday…") is static. To accomplish this, we are using several powerful tricks:
     
    1. Calendar generation is completely dynamic. To generate a view of a different month, we are setting the following fields in the form under myFields/currentMonth:
      • firstDay [date field in XML format (YYYY-MM-DD); set to the first day of the month that you want to view the calendar for - i.e. for May 2007, set to "2007-05-01"]
      • numberOfDays [integer; number of days in the month that you want to present; i.e. for May 2007, set to "31"]
      • mondayOffset [integer; weekday of first day of the month; Sunday=0, Monday = 1, Tuesday = 2, etc. I.e. for May 2007 that starts on Tuesday, set to "2"]

      Note that if you wanted to extend this calendar to show additional months, you could do so by adding rules to set these parameters for different months. It's also easy to move this logic to a web service or form code - thus eliminating the need to maintain a static list of months.
       
    2. Horizontal Repeating Sections wrap when placed inside a table. The wrapping point is determined by table width. This allows us to set up a 7-day-long week.

    3. Conditional formatting works just as expected on horizontal repeating sections. This allows us to highlight today's date, set red background for days marked with an exclamation sign, and set correct background color for weekends.

    4. Default values help us create a necessary number of instances of the horizontal repeating section to cover for the longest month, even if it starts on Saturday. We need 6 instances to cover for "blank" days before the first day of the month, plus a maximum of 31 days in a month = 37 instances. To accomplish this, you can follow the technique from this article.
    5. Rules provide a mechanism for month selection: when a month is selected from the dropdown on top of the form, correct values are set for nodes under myFields/currentMonth.
     
    Of course, there are many uses beyond a calendar, otherwise we would have just built a calendar control, but we couldn't resist sharing this example because it shows off so many tricks.
     
    Alex Weinstein
    Program Manager
Page 1 of 1 (3 items)