The following is an explanation of the 2 types of Authentication. This is well documented on the web!
Classic Mode: This is nothing but Windows Authentication. If any web application is created with Classic Mode Authentication then it cannot applicable to configure forms based authentication. That is basically it.
Claims Based: In SharePoint 2010 for a web application we can enable both windows AND forms authentication. In earlier implementation to do this, we have to create two web applications which has different zones and different authentication. But, with the new claims based authentication a single application can have the capability to configure both windows and forms under single URL. All this is possible because of the authentication framework is built on Microsoft Identify Foundation, and it uses “Geneva” framework to handle this authentication.
Convert from Classic Windows to Claims Based Authentication: To configure a Windows Authentication application to use Forms Based Authentication then you can convert from Classic Mode to Claims Based. But, there is no UI exist for doing this conversion. The only way around is through PowerShell.
WARNING! This cannot be UNDONE!
At the PS Prompt Type the following commands and press enter after each one.
$app = get-spwebapplication “http://<your site’s URL>”
$app.useclaimsauthentication = “True”
$app.Update() Don’t forget the brackets!
IMPORTANT: If an application is created using Claims Based Authentication and if you want to convert to Classic Mode then it is not possible either through the UI or through PowerShell.
Site Page :
- Site pages are pages that are created, edited, and customized by end users.
They are primarily used for the content in a site.
Site pages come in two types—a standard page and a Web Parts page.
A standard page contains text, images, Web Parts, and other elements.
A Web Parts page contains Web Parts in Web Part zones. They have a predefined layout that uses Web Part zones.
Both types of site pages are edited using a Web browser or Microsoft SharePoint Designer.
Site pages are provisioned from a template page that is stored on the file system of the front-end Web server. When a site is provisioned, SharePoint Foundation creates a pointer to the instance of the page template on the file system. This allows SharePoint Foundation to avoid repeatedly creating copies of the pages, which are provisioned each time a site is created.
When a user customizes a site page, the template for the page is then stored in the content database. The page is retrieved from the content database every time it is requested by a user.
A customized page can, however, be reset to the original template page through the Web browser or a tool such as SharePoint Designer.
Customized site pages cannot contain in-line server code. The set of controls that are allowed to run on the page is governed by the safe controls list in the <Drive>:inetpubwwwrootwssVirtualDirectories<port number>web.config file.
It is a recommended best practice to avoid using server-side code on site pages when developing site definitions. If a user later edits or modifies that page, the code will no longer run.
The following are general rules for using server-side code on a site page.
- If the page is uncustomized, server-side code is supported on the page.
- If the page is customized, server-side code does not run, and the page does not render. This includes the code-behind for the page itself.
An administrator can add a PageParserPath setting in the web.config file that allows server-side code to run on pages stored at a specified path. This can be a single, specific page or an entire directory of pages.
Adding PageParserPath settings gives anyone who can upload pages to the specified folders the ability to write arbitrary, full-trust code to the server. Administrators should use extreme caution when providing these settings and understand the security implications to this action.
The following sample shows a PageParserPath setting that uses a wildcard. Adding this PageParserPath will allow anyone with permissions to the master page gallery to upload server-side code. Use extreme caution when adding this type of PageParserPath setting.
<PageParserPath VirtualPath=”/_mpg/*” CompilationMode=”Always” AllowServerSideScript=”true” IncludeSubFolders=”true”/>
Application Pages :
Application pages are used to support application implementations in SharePoint Foundation.
Application pages are stored on the file system of the front-end Web server in the %ProgramFiles%Common FilesMicrosoft Sharedweb server extensions14TEMPLATELAYOUTS directory and exist for every site in a Web application.
This folder is mapped to an Internet Information Services (IIS) virtual directory called _layouts. Every site and subsite will have access to the application pages by using the _layouts virtual directory.
For example, http://myserver/_layouts/settings.aspx and http://myserver/subsite/_layouts/settings.aspx access the same application page on the front-end Web server unlike site pages, which are an instance for the specified site.
* Application pages are not subject to the same restrictions as site pages. They allow in-line code without restriction.
* They cannot, however, use dynamic Web Parts or Web Part zones or be modified using SharePoint Designer.
* Modifying the default application pages is not supported in SharePoint Foundation. Custom application pages can be added to a subdirectory inside the _layouts folder.