SharePoint [architecture series]-SharePoint process and execution model 02

We have learned about the processing and execution trust model of an external HTTP request entering the IIS Working Process (w3wp). This stage is the processing stage that must be passed by the four execution models of SharePoint, the SharePoint Farm solution works with any ASP.. NET applications run in the IIS Worker Process (w3wp). Therefore, the preceding section contains the processing and execution trust model of the field solution.

Here we will continue to talk about the situation of the SharePoint sandbox solution.

Sandbox solution is a new feature of SharePoint 2010. The Sandbox solution is a collection of resources that are directly deployed to the specified library of the top website of the site collection. This library is called "solution Gallery )". We can package the sandbox solution into a Sharepoint solution package (WSP) Just like a field solution ). However, you can directly upload the WSP through the Web user interface (UI) to deploy the sandbox solution, without the need to physically access the server file system or participate by the IT team. Instead, the website set administrator determines who has the permission to add a sandbox solution to his website set. Therefore, the sandbox solution is tempting for the development and management teams.

1. the IIS workflow (w3wp) is assigned to the execution Manager (Execution manager)

If your HTTP request contains a processing model for the sandbox solution, the HTTP request is sent to the IIS Worker Process (w3wp) and IIS Worker Process (w3wp) the request involves the sandbox processing model. At this time, the IIS Worker Process (w3wp) will call the execution manager running in it ), the execution manager takes over the next transfer of processing permissions. For example:

The spuchostservice.exe?spucworkerprocess.exe and spucworkerprocessproxy.exe files in

% ProgramFiles % \ common files \ microsoft shared \ Web Server Extensions \ 14 \ usercode.

 

2. The execution Manager assigns permissions to the sandbox Worker Process (spucworkerprocess)

The SharePoint execution Manager (Execution manager) running in the IIS working process is responsible for finding the code of the sandbox solution in which spucworkerprocess will run) (if no sandbox worker process is running, a sandbox worker process is started ).

Note that the spucworkerprocess started or located by the execution manager is not necessarily on the same server, as shown in the preceding figure.

2.1 spucworkerprocess host machine requirements

Generally, the execution Manager runs any SharePoint Foundation sandbox Code Service (spuchostservice: SharePoint user code host service) in the Sharepoint Server Farm) to start the sandbox Working Process (spucworkerprocess ).

In the windows "service" dialog box, it is called the "SharePoint 2010 user code host" service, for example:

The SharePoint Foundation sandbox Code Service (spuchostservice) runs under a server farm account. This account has the same permissions as the application pool account, this account belongs to the three groups wss_wpg, wss_admin_wpg, and iis_users on the host server that runs the sandbox code service.

2.2 run the Microsoft SharePoint Foundation sandbox Code Service (spuchostservice) physical server locating Mode

The server that runs the SharePoint Foundation sandbox code service can be (but not necessarily) the front-end web server that runs the IIS workflow. You can configure the server to be used in the Management Center application. There are two options for this configuration.

I ,"Local Mode)": This means that each request to the sandbox solution will be processed locally on the same front-end web server running IIS Working Process (w3wp.

II ,"Remote Mode)"(Sometimes called" similarity mode [affinity mode] "): In this mode, start each sandbox process and the execution manager will look for the server that runs the SharePoint Foundation sandbox code service, the server has created an application domain for the same sandbox solution in its spucworkerprocess ). (If another user in another website set has previously requested the same sandbox solution, this will happen ). If a matched application domain exists, the request is sent to the same application domain for processing. If any server running the SharePoint Foundation sandbox Code Service does not have an application domain for the sandbox solution, the execution manager allocates requests to the most idle servers on these servers. Then, the server creates the required application domains and processes requests for the sandbox solution.

Whether the local mode or similarity mode is used, the application domain in the sandbox worker process will remain active after processing the request, if there are other requests for the same sandbox solution, the application domain will be reused.

By default, all sandbox solutions processed by the given server run in the same sandbox worker process, but such configurations can be modified through the object model. Each sandbox solution obtains its own application domain in the common process. This configuration can also be modified through the object model.

2.3 run the "Microsoft SharePoint Foundation sandbox Code Service" physical server allocation method

If your server farm contains several servers, you can start "Microsoft SharePoint Foundation sandbox Code Service" on all physical servers ", you can also choose to start the Microsoft SharePoint Foundation sandbox Code Service on only a few application servers ".

Of course, you can also prepare a high-configuration server to be added to the server farm for running "Microsoft SharePoint Foundation sandbox code service ". In this way, no matter which front-end server in the server farm needs to run the custom code in the sandbox solution, these requests will be sent to this powerful physical server for processing.

Iii. Code Execution and Security Model in spucworkerprocess

As we mentioned above, the sandbox solution is actually a "restricted" solution, which is only safe because of its limitations. Therefore, all code running in the sandbox Worker Process (spucworkerprocess) is restricted by execution and access constraints.

This constraint has two systems:

3.1 The first system is called "server-side object model constraints"

This constraint system applies only to the primary SharePoint Foundation assembly (Microsoft. sharepoint. DLL), the call only applies to Microsoft. sharepoint. part of the Object Model in DLL. This constraint is not only used to call Microsoft from the SharePoint solution created by the user. sharepoint. DLL, and other Assembly from SharePoint (eg: Microsoft. sharepoint. LINQ. DLL) to call Microsoft. sharepoint. DLL assembly.

3.1.1 what are the main restrictions in the Server Object Model constraint system?:

Only some APIs in Microsoft. Sharepoint. dll assembly can be called from the sandbox solution. Calling any prohibited API will cause an exception (this exception will be caught and reported to the user as an error ).

The following are some restrictions on accessible SharePoint object models:

• The spwebapplication class is unavailable. In addition, this means that the sandbox solution cannot access any content outside its hosted website set.
• Almost all classes in the Microsoft. Sharepoint. webcontrols namespace are unavailable, which means that you can only use ASP. NET controls in the sandbox solution.

3.1.2 server-side object model constraints are imposed through the following mechanisms:

This restriction consists of a pair of Microsoft versions that are particularly restricted in % ProgramFiles % \ common files \ microsoft shared \ Web Server Extensions \ 14 \ usercode \ assemblies. sharepoint. DLL assembly (called filling assembly) implementation. The major difference between these two versions and the standard Microsoft. Sharepoint. dll assembly is that they only contain the partial category and members in the standard version.

One of the two filling Assembly programs is loaded by the sandbox Worker Process (spucworkerprocess), the other is loaded by the special proxy process (spucworkerprocessproxy) that runs in full mail mode, and is loaded by the SharePoint FoundationSpuchostservice)Management.

The standard Microsoft. Sharepoint. dll assembly is also loaded in this agent process.

The main work of these two filling program assembly is:

I. filter out prohibited SharePoint classes and members

When Microsoft. Sharepoint. dll is called from any code in the sandbox worker process, it is redirected to the filling program version of the Assembly. If the API to be called is not in the filling assembly, an exception is thrown (this exception is caught and reported to the user as an error ).

When the sandbox solution calls the approved API contained in the filling program set, the first filling program assembly (it is loaded by the sandbox Worker Process spucworkerprocess) this API is passed to the second padding assembly in the fully trusted proxy process (it is loaded by the special proxy process (spucworkerprocessproxy ), the second filling program Assembly passes this API to the standard Microsoft. sharepoint. DLL. Any returned results will be passed back to the original call code. Cross-process interaction can be achieved remotely through. net.

The Sandbox Worker Process and the fully trusted proxy process always start and appear in pairs. If one of the processes crashes, the other stops.

Ii. special restrictions on parameters passed to SharePoint APIs

This restriction is also enforced by the filling program assembly. Some SharePoint APIs can be called from the sandbox solution, but only special restrictions on parameters are passed to these Apis. These input restrictions are enforced by the filling assembly and ensure that exceptions are thrown in the event of a conflict. In SharePoint Foundation 2010, only the spsite (string) and spsite (guid) constructors belong to this application. Although they are available for the sandbox solution, they can only pass the URLs or guids of the website sets that reference the sandbox solution to them.

Because the second padding assembly and standard Microsoft. sharepoint. DLL runs in a fully trusted process, so the above restrictions are not applicable to Microsoft. sharepoint. to call the APIs in the DLL Assembly, we can use these APIs to complete some operations that are prohibited in the sandbox solution. For example, the call to the getlocalizedstring method can be read from the resource file in the file system, while the call to the splist object can be read and written to the content database regardless of the server. (However, files cannot be deployed to disks in the sandbox solution. Therefore, you must install. resx separately as a field solution .)

 

3.2. The second system is called "general constraints"

This constraint system applies to all other calls, including for all other SharePoint programming sets. net Framework Assembly, as long as it is not for the main SharePoint Foundation assembly (that is, Microsoft. sharepoint. DLL.

The above two systems are mutually exclusive: The general constraints do not apply to calls to Microsoft. Sharepoint. dll assembly, you can only select one. In addition, there are miscellaneous constraints generated by the paging rendering system used in the sandbox solution.

"General constraints" are imposed through two mechanisms:

I. First Mechanism

Is defined by the height limit defined in the wss_usercode.config FileCAS PolicyThis file is defined in % ProgramFiles % \ common files \ microsoft shared \ Web Server Extensions \ 14 \ config, and in the web under % ProgramFiles % \ common files \ microsoft shared \ Web Server Extensions \ 14 \ usercode. the policy is referenced in the config file. (Microsoft does not support changing this file .) The restrictions imposed by CAS policies are as follows:

• The code in the sandbox cannot call the unmanaged code.
• The code in the sandbox cannot call the Microsoft. NET Framework 3.5 reflection API.
• The code in the sandbox can only call. NET Framework 3.5 assembly with the allowpartiallytrustedcallersattribute attribute. This will block access to about 2/3 of. NET Framework 3.5 APIs (such as system. printing. In addition, some SharePoint Assembly do not have this attribute.

CAS policy treats Microsoft Office assembly with a strong name as an exception. These assemblies are fully trusted.

Ii. Second Mechanism

YesSecurity tokenTo give the sandbox worker process a low-permission security token.

• This token denies the process's permission to read or write data to the file system.
• This token denies the process's permission to call the network. Therefore, you can only access the resources available on the server that runs the sandbox worker process. For example, you cannot access an external database.
• This token denies the permission of the process to write to the Registry.
• This token denies the permission to call any assembly that is not in the General Assembly Cache (GAC), even if it has the allowpartiallytrustedcallersattribute attribute, otherwise, it will be eligible for calling from the sandbox worker process.

The deployment phase of the sandbox solution runs in the sandbox Worker Process and is subject to the same execution constraints. For example, you cannot deploy files to a disk when deploying a sandbox solution. This is the main reason why the user control (ascx file) cannot be located in the sandbox solution.

 

Iv. Restrictions on resource usage of the sandbox Solution

Since the sandbox solution has granted some permissions, it brings about potential problems, that is, the allocation of SharePoint resources. Imagine that, without control, a user may consume all of the specified resources. Therefore, Sharepoint naturally introduces resource usage restrictions. The following three restrictions are specific:

• Each request (the request is penalized): There is a hard limit on the time required to complete the sandbox solution. By default, this time is limited to 30 seconds. If the sandbox solution exceeds this limit, the request is terminated (rather than the sandbox Worker Process ). (This restriction is configurable, but it can only be performed through custom code for the object model. The related part of the object model is unavailable for the sandbox solution. Therefore, this restriction cannot be changed for any sandbox solution .)
• Each request (process being penalized) has a set of additional resource restrictions (15 in total) applicable to requests ). If the request exceeds a certain limit, the process (and all sandbox solutions running in the process) will be terminated ).
• Daily/website set (website set punished): Each website set is limited by the maximum number of "resource points" per day that can be configured. These points are accumulated based on an algorithm that considers the use of 15 types of resources by the sandbox solution installed on the website. When a website set exceeds the maximum number of points allowed, all sandbox solutions in the site set will be terminated and will no longer run during the remaining time.

5. pagination of sandbox

When the client computer requests a Sharepoint page containing components in the sandbox solution (for example, Web components deployed in the sandbox solution), Sharepoint displays multiple page objects. One page object is displayed in Microsoft ASP. NET workflow (w3wp.exe), while other page objects are displayed in the sandbox workflow. All non-sandbox components are displayed on pages in the ASP. NET working process, and the first sandbox component is displayed on a page object in the sandbox working process. When the page is fully rendered in the sandbox working process, the page is merged into the page object in the ASP. NET process. If the page requested by the user has multiple sandbox components, these components are presented separately on the page objects corresponding to the sandbox worker process. In turn, each such Page Object is incorporated into a page object in the ASP. NET process.

6. Get rid of sandbox restrictions

The Sandbox solution can get rid of the conventional restrictions in two ways.

1. UseClient codeAccess resources that cannot be accessed from the server code in the sandbox solution.

For example, the sandbox solution can contain a custom webpage with JavaScript, and javascript can call the Javascript client Object Model of SharePoint. In addition, the sandbox solution can contain Web Components that host Microsoft Silverlight applications. Later applications can call the SharePoint Silverlight client object model. Any restrictions on the sandbox solution do not apply to client code. There are no restrictions on code execution, resource access, and resource usage.

2. PassFully trusted proxy.

That is, develop a server farm solution, which includes one or more classes derived from spproxyoperation. Each class defines an operation that will run with full trust, you can also use the executeregisteredproxyoperation method to call these classes from the sandbox solution. Specifically, these fully trusted proxy operations will be performed in the same proxy process (spucworkerprocessproxy.exe) that runs the standard Microsoft. Sharepoint. dll assembly. Proxy operations can return data to the sandbox solution.

VII. Other SharePoint execution Conditions

Not all SharePoint implementations depend on IIS Worker Process, sandboxed worker process, or its proxy process ). The following are some examples:

• The timer service of Sharepoint is used to execute preset jobs. It can affect other services. It runs under the owstmer process as a farm account.
• The tracing service of SharePoint runs in the wsstracing process as a local service account.
• SharePoint administration service runs in the wssadmin process as a local system account.

Reprinted: http://www.cnblogs.com/wsdj-ITtech/archive/2012/11/08/2544198.html