Understanding Security Permissions


Even though this chapter treats permissions and deployment separately, you must treat them in practice as one inseparable topic. This section and the previous section on deployment (as they relate to permissions and form features allowable in Web-based forms) are extremely important for planning purposes. Make sure you have a firm grasp on these subjects before you start implementing forms or you will very likely waste a lot of valuable time.

Some Common Rules

First, a couple of rules apply universally to all Web-accessible forms and InfoPath client-accessible forms regarding accessing data that is outside the local domain:

  • Web-accessible forms cannot access data outside the local domain boundaries, which is a security measure.

  • The InfoPath client, although subject to a security prompt, can access data in other domains.

These basic rules are important because if your form is a Web-accessible form and you can not get a form to access data correctly when it previously worked fine, you can waste a lot of time attempting to adjust permissions. If you find yourself in this situation, determine whether the form was previously simply an InfoPath client-accessible form accessing cross-domain data and was re-deployed as a Web accessible form. If this is the case, then adjusting permissions will not help because this behavior is built in to the Forms Server.

Important 

Be careful when re-purposing InfoPath client-accessible forms to be Web accessible. You can easily develop forms using the client that you intend to use in the Forms Server that will not function because of the Forms Server 2007 cross-domain data access limitation.

Using Forms that Contain Code

A term that is commonly encountered since the advent of the .NET technology is managed code. Managed code is, in the broadest terms, simply newer .NET code. There is also an older coding technology called Common Object Model (COM). As administrators, you don't need to know how to code InfoPath forms, but you need to be aware of the security and deployment implications of the two coding technologies that might or might not exist in InfoPath 2007 forms you intend to use with Forms Server 2007. The two broad categories of code-bearing InfoPath solutions are InfoPath managed code-based solutions and InfoPath COM-based solutions.

Planning 

Administrators and planners need to have a general understanding of how the code contained in an InfoPath form will relate to its security level and ultimately affect both where and how the form can be deployed. It might be advisable to have an administrator present at some point in the planning stages of your Forms Server 2007 solutions.

Classic COM-Based Code-InfoPath COM-Based Solutions

InfoPath COM-based solutions run in both InfoPath 2003 and InfoPath 2007 if they do not use controls that are specific to InfoPath 2007. InfoPath COM-based solutions will not run in a Web browser using the Forms Server, but they will run in the InfoPath 2003 or InfoPath 2007 client. If you are unable to get an InfoPath form deployed using Forms Server 2007, be sure to ask whether this form is a COM-based or .NET managed code form.

Note 

For InfoPath 2003 forms, you can find out whether a form is compatible with Forms Server 2007. In Design mode in the InfoPath client, navigate to Tools, Form Options, and select Compatibility. Select the Show Report On Compatibility With InfoPath 2003 check box.

Managed Code Forms-InfoPath Managed Code-Based Solutions

As an administrator, you might get caught with some scenarios that perplex you because you are not a coder. Although you are not expected to be a developer, you need to recognize certain deployment problems and at least be able to ask the developers a couple of questions to help clarify why you can't get certain things working.

InfoPath forms can be designed to work in the older managed code programming model of InfoPath 2003 if they do not implement any of the newer Microsoft Office InfoPath 2007 managed code objects. However, these InfoPath 2003 forms will not run in Forms Server 2007. The newer 2007 managed code model can run in Forms Server 2007. Therefore, if you can get things working and you've been assured that the form has managed code in it, ask whether it's the 2003 or 2007 managed code, because the older code will not work.

Forms with managed code can be partially deployed by users who possess at least contributor permissions. However, it will require an administrator to verify, upload, and activate InfoPath managed code-based solutions.

Best Practices 

If you intend to keep your forms in service from one version to another, it is suggested that you convert your managed code to the 2007 managed code object model. This will not only allow you to take advantage of the new capabilities if you chose but will also give you a consistent code version base. Should it become absolutely necessary to upgrade your forms to a future version, it will be easier if you do not have to span multiple version changes at once. This strategy will also let you amortize your upgrade costs over a longer period of time.

Managed-code solutions using Forms Server 2007 depend on using some of the new .NET Framework 2.0 and Windows SharePoint Services 3.0 programming classes to achieve their flexibility. To create the InfoPath form in a browser, the infrastructure translates the InfoPath .xml form into a byte stream compatible with Web browsers. In this process, it brings the form to life using the new Windows SharePoint Services 3.0 AppDomain object, which is a new .NET Framework 2.0 derived creation. The result is the new .NET security model as adapted in SharePoint Server 2007 and Microsoft Forms Server 2007.

More Info 

For more information on this, see Chapter 31, "Administrating Code Access Security."

Using InfoPath Forms in Custom ASP.NET Pages

There is an XmlFormView control that allows a programmer to display an InfoPath form inside the XmlFormView control on his own Web page. This is more properly an InfoPath 2007 feature versus a Forms Server 2007 capability and is mentioned here because one of its limitations relates to detecting the type of client browser the aspx page is running in.

Forms Server 2007 is capable of detecting its client and will format things accordingly. This benefit is lost when using the XmlFormView control found in the Microsoft.Office.InfoPath.Server.Controls namespace which means your form might not be paginated properly when displayed in different Web browsers.

Controls Available to Forms Server Forms

If you cannot get a form deployed or working correctly, incompatible controls on the form is another possible avenue to look into. Only a certain subset of controls available to an InfoPath 2007 form are usable with Forms Server 2007. Table 21-4 provides a list you might use to inquire of the developers whether any restricted controls were inadvertently used on a form you are trying to use with Forms Server 2007. For example, the form might not originally have been thought of as a form that would be filled in from a Web browser, so it was not designed for the Forms Server.

Table 21-4: Forms Server Controls
Open table as spreadsheet

Available to forms server forms

Not available to forms server

Standard Controls

Standard Controls

Text box

ComboBox

Rich-text box

Repeating and Optional

Drop-down list box

Horizontal Repeating Table

List box

Master/Detail

Date picker

Bulleted List

Check box

Numbered List

Option button

Plain List

Button

Multiple-Selection List Box

Section

File and Picture

Repeating and Optional

Picture

Optional section

Ink Picture

Repeating section

Advanced Controls

Repeating table

Vertical Label

File and Picture

Scrolling Region

File Attachment

Horizontal Region

Advanced Controls

Choice Group

Hyperlink

Repeating Choice Group

Expression Box

Choice Section

 

Repeating Recursive Section

 

Custom Controls

 

All

Understanding Browser Compatibility Issues

The whole purpose of Microsoft Forms Server 2007 is to allow end users to fill in and view forms using a Web browser. Microsoft has identified four levels of Web browser compatibility, ranging from fully compatible (level 1) to not supported (level 4). Table 21-5 is an outline of browser-supported features that might be helpful to you when working with forms in the browser.

Table 21-5: Browser Support Level Feature Notes
Open table as spreadsheet

Compatibility level

Supported features

1

Provides full fidelity and the best experience with the online form.

2

Provides a fully functional experience. However, certain features, such as a date picker, might not be available on some browsers.

3

Does not provide full fidelity. Certain features might not work, and rendering will differ significantly between browsers.

4

No support and possible blocking (page might be prevented from loading).

Table 21-6 outlines a browser support matrix that can be useful when needing to troubleshoot Office Forms Server 2007 and your client browser interactions.

Table 21-6: Browser Support Matrix Based on Table 21-5 Levels
Open table as spreadsheet

Browser support matrix

Operating system

Browser

Level 1: Windows SharePoint Services Forms Administration

Windows 98, Windows Me, Windows 2000, Windows XP, Windows Server 2003

Internet Explorer 6.x and Internet Explorer 64-bit version

Level 2: Internet, Windows SharePoint Services Site Administration, Form Filling for a majority of users

Windows 98, Windows Me, Windows 2000, Windows XP, Windows Server 2003

Internet Explorer, FireFox,
Netscape 7.2 (moving to 8.x)

 

UNIX/Linux

 
 

Mac OS X

FireFox, Safari 1.2

Level 3: Limited support

UNIX/Linux/Windows (versions other than above)

 

Level 4: No support

Everything else

Everything else

Data Connections Used with Forms Server

When comparing Forms Server 2007 forms with the InfoPath client, there are some limitations when using data connections. It is common to use ADO.NET DataSets to pass database table information back and forth in InfoPath 2007 forms. Similar to three-tier/ n-tier classic ADO.NET applications when returning a recordset from the back-end database to a client application in a simple client-server scenario, the recordset keeps an internal duplicate copy of all data. When changes are subsequently made to the data and then resubmitted to the database, the underlying data on the physical database is compared with the internal copy and if the current values in the raw database do not match the saved copy, a concurrency error is thrown. However, when passing the same recordset back from the middle tier to the client in a three-tier scenario after updating the physical database, the changes-that is, the internal duplicate copy made of the data-are lost. A similar situation happens with Forms Server 2007 forms using ADO.Net DataSets when changes are made to a dataset through a Web service; the changes are not automatically tracked and retained. You can think of what InfoPath calls a DataAdapter as simply a connection to some sort of data store.

As an administrator, you deploy a form that had been working as expected and all of a sudden it stops working. If the part that stops working is obviously a problem related to a data store connection, you might want to consider the following:

  • InfoPath design-time DataAdapters become read-only when used on the Forms Server.

  • On a Forms Server, Human Work Flow services adapters are not supported.

Except for the limitations just noted, the following Data Connection types are supported on Forms Server 2007:

  • Database

  • E-mail

  • Http Post

  • SharePoint (native API for same domain data connections, DAV for cross-domain)

  • SharePoint List

  • Web Services

  • XML File

Forms Server 2007 Compatibility with InfoPath 2003

The day has arrived when coders cannot be completely unfamiliar with administrative tasks and be effective. Likewise, although not expected to code InfoPath forms, administrators need to be familiar with some of the tasks and concepts used in the development cycle. Because of the way the InfoPath forms and administrative tasks interact with each other (for example, during deployment), a knowledgeable administrator is a valuable asset to have at the project planning stage.

Microsoft Visual Studio Tools for Applications (VSTA) is the new programming development environment for working with Microsoft Office InfoPath 2007, Forms Server 2007, and SharePoint Server 2007. In relationship to InfoPath 2007 forms, these are the managed-code classes and infrastructure used for writing custom business logic. Because both Forms Server 2007 and SharePoint Server 2007 implement substantially the same functionality regarding InfoPath forms, you can use both browser-enabled forms and client forms to fill in and submit InfoPath forms.

Compatibility with Existing InfoPath 2003 Forms

SharePoint Services 2007 includes built-in compatibility with existing InfoPath 2003 forms regardless of whether they use manage code or the classic COM object models. These forms use the Microsoft.Office.Interop.InfoPath.SemiTrust.dll and its programming objects.

These forms do not run in the Microsoft Office Forms Server 2007, but they will run in the InfoPath client application. Programmers can continue to work with InfoPath project files created using either InfoPath 2003 (Microsoft Office InfoPath 2003 Toolkit for Visual Studio .NET) or InfoPath 2007 (Visual Studio 2005 Tools for the Microsoft Office System and VSTA).

Note 

The end user needs .NET Framework 2.0 to run forms compiled with Visual Studio 2005 Tools for the Microsoft Office System and VSTA for InfoPath 2007.

For forms compiled with the Microsoft Office InfoPath 2003 Toolkit for Visual Studio .NET, .NET Framework 1.1 needs to be installed on the client machine.

Using New InfoPath Forms

New forms can be created by using Visual Studio 2005; these forms will run in either InfoPath 2003 or InfoPath 2007. If you want to create an InfoPath 2007 form, go to InfoPath's design GUI under Tools, Form Options, Programming and select the InfoPath 2003 code compatibility option.

Although the classic COM interfaces, such as those found in the MSXML2 dll and the InfoPath-compatible Microsoft.Office.Interop.InfoPath.SemiTrust.dll, are available for use, Forms Server 2007 does not support their use. Therefore, you will not be able to browser-enable your COM code-based forms.




Microsoft Office Sharepoint Server 2007 Administrator's Companion
MicrosoftВ® Office SharePointВ® Server 2007 Administrators Companion
ISBN: 0735622825
EAN: 2147483647
Year: 2004
Pages: 299

Similar book on Amazon
Microsoft Office SharePoint Server 2007 Best Practices
Microsoft Office SharePoint Server 2007 Best Practices
Microsoft SharePoint 2010 Administrator's Companion
Microsoft SharePoint 2010 Administrator's Companion
Professional SharePoint 2010 Administration
Professional SharePoint 2010 Administration
Inside Microsoft  Office SharePoint  Server 2007
Inside Microsoft Office SharePoint Server 2007

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net