At the SharePoint conference, I had an opportunity to discuss a new feature that will affect the behavior of all Web Parts - old and new.
In 2010, contributor rights are being changed in 3 distinct areas:
- Type of files that must be downloaded explicitly
- The ability to change HTML markup in pages
- The ability to change web part properties
These changes are being made because with the addition of the new Client Object Model, cross-site scripting (xss) becomes a major concern to the health of your SharePoint system.
That's right, the Client Object Model (CLOM) is so powerful and easy to use (imagine cut/past operations!) that XSS attacks from within the trusted membership can become a very serious matter. To be fair, this has always been the case with contributors being able to change markup but the level of difficulty in reading/writing data to a SharePoint from the client was often seen as deterence factor. That obviously changes if you have a client-side om designed specifically to manipulate your site.
Back to Web Parts...
The behavior of every single web part in existence is going to change. The new default behavior for who can view/edit web part properties is to PROHIBIT contributors from viewing/editing properties.
There are two (2) mechanisms that can come into operation to prevent contributors from viewing/editing properties:
- New Object Model attribute: RequiresDesignerPermissionAttribute
- New SafeControl attribute: SafeAgainstScript
These mechanisms apply permission-based restrictions on whether a contributor can view and/or edit web part properties.
It's also worth noting that these mechanisms operate independently of each other with the Object Model attribute having the most authortity of the two.
What is the default behavior?
By default, contributors are NOT allowed to view or edit custom web part properties. All SafeControl entries default to SafeAgainstScript=false.
Here's two tables to help illustrate how the safeguards work to enable/disable editing by a contributor.
In the first table, note the row with SafeAgainstScript=No.
|
RequiresDesignerPermission = false (or not applied) |
|
SafeAgainstScript |
Designers and higher |
Contributors |
|
Yes |
Ok |
Ok |
|
No |
Ok |
Not Allowed |
The table above basically applies to every legacy part that is simply installed on a 2010 server. In short, your web part's use case scenarios will change.
The next table outlines how a web part built using the new Object Model attribute would operate.
|
RequiresDesignerPermission = true |
|
SafeAgainstScript |
Designers and higher |
Contributors |
|
Yes |
Ok |
|
|
No |
Ok |
Not Allowed |
Not the subtle difference in behavior. The RequiresDesignerPermissionAttribute always forces the user to have the appropriate security permission regardless of the SafeAgainstScript attribute.
The ONLY time these mechanisms are not enforced is when a web part has been personalized and the property is scoped to the User or if the web part has been added as a Personal Web Part.
What are the impacts of the new XSS safeguard?
- All web parts, by default, will behave differently in 2010.
- User scenarios need to be reevaluated. If you have a web part that was specifically designed with contributor-level users in mind, investigation is needed to determine how to best enable that functionality on a 2010 server.
- The Sandbox does not in any way offer more protection for the XSS scenarios. All of the rules apply for Farm and Sandboxed solutions.
- Developers have additional flexibility to manage who can view/edit properties based on permissions.
- Administrators will add "why is SafeAgainstScript=true" to their list of pre-installation validation questions.
I'll cover the other 2 contributor restrictions in coming posts.
In the meantime, start getting ready for the calls asking "how come I can't edit the properties?". We all know those calls are going to come in... :)
-Maurice