SharePoint [architecture series]-SharePoint webpage, parsing, and security)

Microsoft SharePoint Foundation has two types of pages: Application page and Site Page ).

Both application page and Site Page inherit the layout from the same master page.

The application page is most similar to the traditional Microsoft ASP. NET 3.5 web page. However, the application page is not directly derived from system. Web. UI. Page, but from layoutspagebase or unsecuredlayoutspagebase. The application page does not run in safe mode and may contain embedded code. Only the field administrator can install the application page.

A website page is a page created, edited, and customized by end users. It can be customized and modified by users. Website pages are set through the template page stored on the front-end web server's file system. When setting a website, Sharepoint Foundation creates a pointer to the page template instance on the file system, which is stored in the content database of the website that uses the website page. In this way, Sharepoint foundation can avoid repeated creation of copies of pages to be set each time a website is created.

There are two types of website pages: standard page and Web Part Page ).

Standard page contains text, images, Web parts, and other elements. These pages are wiki-enabled pages that can contain Web controls and Embedded Web components. Standard page is derived from the wikieditpage class instead of system. Web. UI. Page.

Web Part Page: as the name suggests, it is a Web Part page that contains the Web Part zone. The Web Part Page is derived from webpartpage instead of system. Web. UI. Page.

Sharepoint2010 adds the third website page ):PublishingpageThis type of page is only used in the publishing sites. On the publishing website, authors and approvers (author and approvers) use the publishing feature function to create content for website users to access. Generally, a publishing website is bound with an approval workflow, so that the content to be released can be quality grasped before it is officially released. Publishing pages are usually created based on page templates such as page layouts. page layouts provides a consistent structure for publishing pages, which can be customized.

SharePoint also includes a set of built-in Web pages for mobile devices. SharePoint Foundation mobile Web pages are much simpler than non-mobile Web pages. Mobile web pages do not use ASP. NET master pages/content pages, nor are they divided into application pages and website pages. SharePoint Foundation mobile Web pages are all application pages and are located in the \ _ layouts \ mobile folder. SharePoint Foundation mobile web page is particularly similar to a website page in a certain aspect: If the page contains a mobile Web Part adapter, you must register the adapter as a security control; otherwise, the adapter will not be rendered

The following is a general description of the web page of SharePoint.

Next, let's focus on the application page and site page to see their specific differences:

1. Purpose (typical purpose ):

Application pages focuses on function-oriented. For example, the page provided to the user for creating a new Web application is the application page, on the Creation page, enter the required parameters and click OK to create a new Web application.

Website pages focus on content-oriented ), for example, in a standard team site, you can view the list pages of the current website as website pages.

Of course, this distinction is not mandatory and sometimes mixed. A third party can develop a user-defined Web part, specific user operations (such as List Management and Information Processing) are implemented on this Web part ..., Like the functions on your application processing interface), and then load the Web part to the website page, so that the website page has the "function" operation. Sometimes this method is more flexible and convenient than developing an application page.

2. Custom ability ):

The website owner and users with corresponding permissions can customize and modify the website page, you can also add a new ascx page to the site pages gallery area ).

However, you do not have the permission to customize and modify the application page. Only the Administrator has the permission to install a new application page on the website.

3. inherit class inheritance ):

Application pages are inherited fromLayoutspagebaseClass orUnsecuredlayoutspagebaseClass.

Website pages are inherited fromWikieditpageClass orWebpartpageClass.

All the base classes mentioned above inherit from ASP. NET'sPageClass.

4. Web Part support ):

Application pages do not have Web Part zones or dynamic Web parts, but they can contain static Web parts, which has little practical value, because developers can use traditional controls to implement functions on this page.

Website pages can contain both static Web parts and dynamic Web parts and Web Part zones.

5. storage location ):

Application pages are stored in the file system of the front-end web server, the location is under the _ layouts virtual directory of the corresponding web application. This virtual directory is mapped to the actual disk directory of the (Map To) Server File System, this directory is: % ProgramFiles % \ common files \ microsoft shared \ Web Server Extensions \ 14 \ template \ layouts directory or its subdirectory.

Website pages are usually dividedUncustomized pageAnd customized page (in sps2003Ghosted pageAndUnghosted pageThe two terms are described as follows.

I. The website page has not been customized and modified by the customer: When we create a new site, all the pages are uncustomized pages, which are directly stored on the front-end web server (front-end web server) page Template on the disk (located in% ProgramFiles % \ common files \ microsoft shared \ Web Server Extensions \ 14 \ TemplateDirectory and its sub-directories (eg: sitetemplates and features sub-directories are commonly used). In other words, the page of this new site is actually "nonexistent ", they are just a "tag" (that is why they are called ghosted page in sps2003). If a user accesses a page, sharePoint automatically finds the real page template file from the disk, loads it into the memory, parses it, and compiles it into an independent DLL file (for performance, this dll will be cached on the disk to avoid repeated compilation next time), then load the DLL and run and output it.

Ii. website pages are customized or modified: Once the website page is modified by a tool such as Microsoft SharePoint designer, Sharepoint automatically saves the modified file content to the content database used by the site, it becomes a customized page. When a user accesses this page, Sharepoint will automatically read the content of this file from the content database, and then parse and run it. In this case, Sharepoint will no longer compile it into an independent DLL file. In fact, Sharepoint will load the structure of this page in the memory, run it, and then output it, then it is detached from the memory to save memory.

Note: Although uncustomized site page is stored in the file system, it actually has records in the content database. This record is mainly used for storage. the storage path of the ASPX page file, which is the pointer to the page template instance on the file system. Why is this done? It is because the uncustomized site page is usually shared by several websites, any website that calls the uncustomized site page will store the page path in their content database. For example, the content database of each team site has a record pointing to the home page of the team site. This homepage is the uncustomized site page. When you open the webpage related to the team site, the system will retrieve and display the homepage according to the path of the stored homepage. Of course, if a website makes a personalized modification to the homepage, it will become a customized page, and the modified content will be saved to the content database, the path records saved in the original content database will be removed. However, you can reset the custom page to the original template page through a Web browser or a tool such as SharePoint designer, that is, you can discard user customization and re-use the previous page template, in the content database, the pointer records directed to the page template instance on the file system are retained. Sometimes, the uncustomized site page will be referenced as a page template by the page instance stored in the content database. Remember: as long as the page on the website is not customized or modified, the record in content database is only a path pointer used to point to the storage path of the page in the file system.

6. Availability ):

An application page can be accessed by any website in its webapplication.

However, a website page can only be accessed by users on the website where it is deployed. Although uncustomized site pages can also be accessed by multiple websites, however, this requires specific means (those websites must be provided as part of the feature or part of the site definition ).

7. parsing mode ):

Application page"Direct)"Method for parsing. The so-called direct mode refers to the use of standard ASP. NET page parser. When this page is accessed for the first time, it will be parsed by parsed, compiled (Compiled ), and cached in the memory of the front-end web server until the application domain or IIS associated with the request is cleared (recycled ). If there are other access requests before the collection, it will be provided directly to the requestor from the cache without re-parsing and compiling.

There are two types of website pages:

I. uncustomized site pagesAlso through"Direct)"Method for parsing.

Ii. customized Site pagesThe new web page added to the site page gallery is"Safe mode )".

The security mode resolution features are as follows:

(I) Only controls (including Web parts) registered as "safe" in the web. config file of the Web application can be parsed and rendered.

(Ii) inline server-side code is not allowed in safe mode. If you embed inline server-side code in the webpage, the system returns an error page. The so-called inline server code is as follows:

<SCRIPT runat = "server">
[Code is here]
</SCRIPT>
Or
<Asp: button onclick = "mybuttonhandler ()"/>

Code behind and embedded Javascript are allowed because they are compiled into separate assembly and deployed.

(Iii) the customized Site Page is different from the Application page processed in direct mode, because it does not need to be compiled by the system like the application page. Therefore, it does not work if you add such items as compile commands to such webpages.

It should be noted that safe mode parsing and safe mode processing and safe mode rendering mentioned in other SharePoint documents) it means the same thing.

Why does SharePoint introduce this security mode??

You can think about it. Since users are allowed to customize their webpage behaviors, the resulting problem is that users may add Execution Code to the personalization process, if the code is safe and efficient, no one can ensure that all users do this. Another reason is that this kind of Web Page cannot be compiled, which is not hard to understand. Imagine that if hundreds of users have made personalized customization, and this kind of personalized Web page must be re-compiled before it can be displayed, so how much pressure will be placed on our server, and the compiled results should be cached in the server memory. The cached content can only be cleared by recycling the application domain, however, the problem is that the collection of application domain will clear the assembly, and the Assembly will contain other webpage content. You can't just clear the custom webpages you want to remove, or empty them all, either they are retained, which is obviously unreasonable. In addition, the number of assemblies that can be loaded in an application domain is limited in the system. Therefore, all these factors determine why SharePoint will introduce security mode resolution and why this resolution method should work according to such rules.

As we mentioned earlier, inline server-side code is not allowed in safe mode resolution, in fact, it should be "normal" that it is not allowed. In fact, Sharepoint is not so bad, it also has to leave a retreat, it allows you to modify the web of Web application. config to allow inline server code or insecure controls, that is, to the Web. add the <pageparserpath> sub-element to the <safemode> element under the <SharePoint> node in config, you can specify the webpage to which you want to add inline server code or unsafe contrl by setting related properties of this element ). Obviously, this operation is dangerous, so you must be very careful, because the unblocking can be a single specific page or a whole directory page. Adding pageparserpath allows anyone who uploads the page to the specified folder to write any fully trusted code to the server. Therefore, administrators should be especially careful when providing these settings. They should be aware of the security risks in advance and try to ensure the security and performance of the system.

An example of a threat:

If you allow all *. add inline server code to a webpage named in aspx mode. If you have special intentions, you will personalize an aggressive webpage and use getinfoasmymind. the name of aspx can certainly be obtained through the SharePoint inspection rules and the right to run the relevant code. The result is to attack and harm your system.

The following example shows how to set pageparserpath with wildcard characters.

Adding this pageparserpath will allow anyone with the master page style Library permission to upload server code. Be careful when adding pageparserpath settings of this type.

<SharePoint>
<Safemode...>
<Pageparserpaths>
<Pageparserpath virtualpath = "/_ MPG/*" compilationmode = "always" allowserversidescript = "true" includesubfolders = "true"/>
</Pageparserpaths>

Unsafe control refers to controls added by the editing tool (for example, controls added by using SharePoint designer ). However, whether the <pageparserpath> element is used to enable (enable) unsafe control (unsafe control) of a webpart, it must be registered as secure before it can be allowed.

You can also use the <pageparserpath> element to enable the compilation function that allows you to customize a website page. In this way, the web page will be compiled into a DLL and stored in the cache. Obviously, this method is similar to the application page compilation method, the advantage of doing so is to speed up the access response of the webpage. Therefore, it is only valid for webpages that are frequently accessed.

Reprinted: http://www.cnblogs.com/wsdj-ITtech/archive/2012/11/02/2543465.html