WebBrowsable will make the property appear in the ToolPane or EditorPart of the WebPart.
Personalizable will allow the property to be stored and persisted in the personalization store. There is an enum in which you can specify weather this property will store per user values or a single value for all users.
SafeControl
Solution Gallery – The Solution Gallery is the recommend placed to deploy a Web Part by using a sandboxed solution. It provides monitoring and security for your Web Parts by default. For more information about sandboxed solutions, see Sandboxed Solutions in SharePoint 2010.
global assembly cache — A global location where signed assemblies can be deployed, especially code for workflows, events, and Feature receivers. The global assembly cache enables you to share assemblies across numerous applications. The global assembly cache is automatically installed with the .NET runtime. Components are typically stored in C:\Windows\Assembly.
bin directory — A folder stored in your web application root directory; deployment to the bin directory should be limited to controls and Web Parts . The location of this folder is determined when the website is created in Internet Information Services (IIS). In SharePoint Foundation, this can occur either through the Central Administration site, or by manually creating a new website in IIS manager.
If a bin directory does not exist, you must add one manually. Do not store Web Parts in the local _app_bin directory, which is reserved for use by Microsoft.
For more information, see How to: Find the Web Application Root.
Personalizable will allow the property to be stored and persisted in the personalization store. There is an enum in which you can specify weather this property will store per user values or a single value for all users.
SafeControl
Solution Gallery – The Solution Gallery is the recommend placed to deploy a Web Part by using a sandboxed solution. It provides monitoring and security for your Web Parts by default. For more information about sandboxed solutions, see Sandboxed Solutions in SharePoint 2010.
For more information, see How to: Find the Web Application Root.
| Deployment Location | Advantages | Disadvantages |
|---|---|---|
| Solution Gallery | By default, code deployed to the Solution Gallery is run in partial trust. Code in the Solution Gallery also have resource usage monitoring to ensure the health of the farm. The Solution Gallery is specific to a site collection. | All of the object model in SharePoint Foundation is not available in the Solution Gallery. |
| global assembly cache | By default, assemblies run with full trust. They are globally installed, so they work in any web application. The global assembly cache can contain multiple versions of the same assembly. | Generally there are no code access security (CAS) restrictions on code installed to the global assembly cache. Also, an assembly deployed to the global assembly cache is cached, so if the assembly is rebuilt, it is not automatically updated on the SharePoint site. You must force SharePoint Foundation to reload the assembly by resetting Internet Information Services (IIS). |
| bin directory | By default, assemblies run with partial trust. Code that runs from this directory has a low level of CAS permissions. Because administrators must explicitly raise permissions that have been granted to a Web Part so it can function properly, they often prefer that assemblies run in the bin directory with a known set of required CAS permissions. A bin directory is specific to a web application. This makes it possible to isolate code to a particular web application, but we recommend that you use sandboxed solutions for security protection. | In order for the Web Part to run in multiple web applications, you must deploy it to the global assembly cache. Deploying assemblies to the bin folder may affect performance because there is additional time required to load the .NET Framework runtime to manage code access security permissions. |
There are two ways to elevate permissions:
- Recommended method — Create a new trust policy file and point your web.config file at the new file. This option is more complicated but it gives you a precise attribution of permissions for your Web Parts.
For more information about trust policy files, see Securing Web Parts in SharePoint Foundation. - Optional method — Raise the trust level of the bin directory. In the web.config file in the web application root, there is a tag named
with a default attribute of level="WSS_Minimal". You can change this level to WSS_Medium. Although this option is simpler, it grants arbitrary new permissions that you might not need and is less secure than creating a new trust policy file.
than creating a new trust policy file.
Creating a SafeControl Entry
A fundamental assumption of the SharePoint Foundation technology is that untrusted users can upload and create ASPX pages within the system that is running SharePoint Foundation. To prevent untrusted users from arbitrarily adding server-side code within ASPX pages, SharePoint Foundation provides a SafeControls list.
The SafeControls list is a list of approved controls and Web Parts specific to your SharePoint site that you have designated as safe for invocation on any ASPX page within your site. This list is contained in the web.config file in your web application root.
A SafeControl entry is an XML-based declaration of a Web Part that has the following form.
The SafeControl entry uses the assembly name, namespace, versioning information, and, if it is signed, it also requires a public key token to verify that the control is safe. If a Web Part assembly is signed, you can use the Strong Name Tool to retrieve the public key token for use in the SafeControl entry. The following command will retrieve the public key token for an assembly.
sn -T AssemblyName.dll
The SafeControls list is a list of approved controls and Web Parts specific to your SharePoint site that you have designated as safe for invocation on any ASPX page within your site. This list is contained in the web.config file in your web application root.
A SafeControl entry is an XML-based declaration of a Web Part that has the following form.
The SafeControl entry uses the assembly name, namespace, versioning information, and, if it is signed, it also requires a public key token to verify that the control is safe. If a Web Part assembly is signed, you can use the Strong Name Tool to retrieve the public key token for use in the SafeControl entry. The following command will retrieve the public key token for an assembly.
sn -T AssemblyName.dll
Web Parts in Microsoft SharePoint Foundation provide a powerful way for users to interact with other systems. SharePoint Foundation has built-in security settings to restrict the access that a Web Part has to underlying systems. A developer can create custom security policy files to give a Web Part greater access to the underlying system
Web Parts can also be created in a sandboxed solution. By default, a sandboxed solution has restricted access to the underlying system. This provides greater security and monitoring of the Web Part. For more information about sandboxed solutions, see Sandboxed Solutions in SharePoint 2010.
Web Parts can also be created in a sandboxed solution. By default, a sandboxed solution has restricted access to the underlying system. This provides greater security and monitoring of the Web Part. For more information about sandboxed solutions, see Sandboxed Solutions in SharePoint 2010.
Code Access Security (CAS) is a resource-constraints policy that limits the access that an assembly has to protected system resources and operations. SharePoint Foundation has built-in security policies built on top of the built-in security policies of ASP.NET. By default, SharePoint Foundation uses a minimal set of permissions in order to protect the server and underlying infrastructure from malicious code.
If your Web Part needs greater access than what is provided in the minimal settings, there are a number of ways to increase the permissions of your Web Part, but only one is recommended. You can create a custom CAS policy for your Web Part, or increase the overall trust level of the server farm in the web.config file. This is a security risk and is not recommended. For more information about deployment, see Deploying Web Parts in SharePoint Foundation.
SharePoint Foundation is a partial trust application by default. SharePoint Foundation can use the ASP.NET built-in trust levels but defines trust levels of its own:
- WSS_UserCode
- WSS_Minimal
- WSS_Medium
These trust levels extend the ASP.NET trust levels for use with SharePoint Foundation. Trust levels are defined in policy files that can be found on the file system of each Web server.
Important By default, the built-in SharePoint Foundation policy files in SharePoint Foundation, named wss_usercode.config, wss_minimaltrust.config, and wss_mediumtrust.config, are found in %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\CONFIG directory.
By default, SharePoint Foundation applies the WSS_Minimal trust level for the virtual server. This trust level grants all of the permissions in the ASP.NET Minimal trust as well as Web Part connections. The WSS_Minimal policy restricts the Web Part from accessing many resources for advanced operations, including the object model and file operations.
The WSS_Medium trust level grants greater access to the environment. Also, WSS_Medium allows access to the SharePoint Foundation object model and file operations including read, write, append, and path discovery. This trust level also allows access to environment variables.
The following table outlines the specific permissions granted with the WSS_Medium, WSS_Minimal and WSS_UserCode policy files in the ASP.NET 2.0 environment.
| For more information about Code Access Security, see Using Code Access Security with ASP.NET and also Security Guidelines for .NET Framework 2.0. |
SharePoint Foundation has the ability to deploy a CAS policy file with a solution. We recommend that you use the permissions for sandboxed solutions as listed in the wss_usercode.config file, but you can also create custom permissions for your Web Parts and use SharePoint Foundation to handle the deployment.
The following code example shows the basic structure of a CAS policy file in a SharePoint Foundation solution package.
The list below includes some general guidelines that apply when you use a section in your solution manifest.
- There can only be one
per solution manifest. - There can be multiple
nodes. - Every
node can only contain one node. - Every
node can only contain one node. - Each
node can contain multiple nodes. - There can be multiple
nodes under the node.
Strong naming uses a private key to digitally sign an assembly. Strong naming also stamps the assembly with a public key to validate the signature. This technique guards against unauthorized versions of a Web Part. If the public key fails to validate the digital signature, SharePoint Foundation refuses to run the module.
When you deploy a Web Part to the bin, the recommend practice is to strong name the assembly. When deploying a Web Part to the global assembly cache, the assembly must have a strong name. An assembly without a strong name is not recommended in SharePoint Foundation.
To sign an assembly, you use the sn.exe tool that is included with the Microsoft .NET Framework Software Development Kit (SDK). For more information about the .NET Framework SDK, see SDKs, Redistributables & Service Packs. The sn.exe tool is also used to extract the public key that is needed to register your control as safe in the SafeControls list. For more information about using the sn.exe tool, see Strong Name Tool (Sn.exe).
A fundamental assumption of the SharePoint Foundation technology is that untrusted users can upload and create ASPX pages within the system that is running SharePoint Foundation. To prevent untrusted users from arbitrarily adding server-side code within ASPX pages, SharePoint Foundation provides a SafeControls list.
The SafeControls list is a list of approved controls and Web Parts specific to your SharePoint site that you have designated as safe for invocation on any ASPX page within your site. This list is contained in the web.config file in your web application root.
A SafeControl entry is an XML-based declaration of a Web Part that has the following form.
The SafeControl entry uses the assembly name, namespace, versioning information, and, if it is signed, it also requires a public key token to verify that the control is safe. If a Web Part assembly is signed, you can use the Strong Name Tool to retrieve the public key token for use in the SafeControl entry. The following command will retrieve the public key token for an assembly.
No comments:
Post a Comment