Customizing the Login Page in SharePoint 2007

Microsoft SharePoint 2007 you have the option of using forms authentication, but the out-of-the-box forms-based login experience is fairly smooth. Not bad, if you're doing something for internal use, but if you're doing something for internal use, then probably you are using Windows authentication. Forms authentication is normally found in the external customer-facing or in places where corporate branding is big business, and master pages play an important role in presenting a consistent look through a SharePoint site. But when you apply a master page to a publishing site, or edit default.master in a team site, you'll quickly realize that does not alter the appearance of the logon page. In this article we take a look at what is and what needs to do to get your login page in line with its corporate brand.

Where does the login.aspx page reside?
When you try to view a protected page in a forms authenticated site, SharePoint redirected to the login page (Figure 01). At the logon screen, take a good look at the URL in the browser page warning that login.aspx is in the _layouts folder. If you go to the directory that hosts the SharePoint application, you'll quickly realize that there is no _layouts folder in the directory itself. This revelation is not surprising to most since many of the pages you see in SharePoint does not really exist in the file system. But if you open the Internet Information Services (IIS) Manager and navigate to the SharePoint site, you will find that the _layouts folder is actually a virtual directory that points to the following real-life directory on the server (assuming you installed in the location default):
C:\Program Files\Common Files\Microsoft Shared\Web Server Extension\12\template\layouts

The folder contains application designs and system pages used by all SharePoint sites on the server. Upload a new document to a site that ends in the upload.aspx page folder of designs. View people who access the site will be people.aspx page. And if you're trying to login, it connects to the login.aspx page. There are 400 pages in the directory, each of which has its own particular point and purpose, so it's impossible to go into detail on every page.

Figure 1 – the login.aspx page

Global consequences of changing files in the _layouts folder

Armed with the location of the pages on the implementation of SharePoint, you may be tempted to dismiss an editor and start hacking away at them, but you should probably know what you're getting into before going down that road. Remember how the _layouts folder of your SharePoint site is a virtual directory that points to C: \ Program Files \ Common Files \ Microsoft Shared \ Web Server Extension \ 12 \ template \ layouts? Well, all SharePoint sites on the server is configured the same way. This means that when you change anything in the _layouts folder of a site will change to every single SharePoint site on your server. It also means that you are editing a single version of the file on your system, so it is best to back up the contents of the folder. Otherwise you need to reinstall SharePoint to get the files back into service if you have a nasty accident.


Creating a site-specific _layouts virtual directory
Depending on your situation, apply changes to all sites on the server may or may not be a bad thing. If all sites on the server of the need for exactly the same make, design and functionality, then go ahead and make the change directly in the standard design folder (after backing it up). But it may well only be in a situation where each site has to be different, so that the implementation of radical change to all sites won't work. What do you do when you are in that situation? You make a copy of the shared folder designs specifically for your site, and make changes in the copy of that site-specific. To do this, take the following actions

1.) Navigate to the C:\Program Files\Common Files\Microsoft Shared\Web Server Extension\12\template\ folder
2.) Select the layouts folder and copy it
3.) Navigate to the root directory of your SharePoint site
4.) Paste a copy of the layouts folder in your SharePoint directory
5.) Rename the layouts folder _layouts
6.) Open the IIS manager snap-in
7.) Expand your SharePoint site’s website entry
8.) Right click on the _layouts virtual directory (you may also see a non-virtual _layouts folder) and select Properties from the context menu
9.) On the virtual directory tab, click the Browse button next to the Local Path textbox to display the directory selection dialog
10.) Navigate to the _layouts folder you just created in your SharePoint site, select it, then click OK
11.) Click OK to apply the change to the _layouts virtual directory

Now you can make changes in the _layouts folder for your SharePoint site without it affecting other sites on
your server.

Warning: some operations in SharePoint Central Administrator, like extending a site or changing the authentication type for a zone, can “reset” the _layouts virtual directory in your SharePoint sites so they point back to C:\Program Files\Common Files\Microsoft Shared\Web Server Extension\12\template\layouts. When this occurs, just go back into the IIS manager snap-in and point the virtual directory back over at the _layouts folder copy for your site.

Login.aspx and its Master Page

When you open the login.aspx page you'll quickly discover is a content page that contains the marking of a title, a layout table, username text, password text, a login button, a "Remember Me" check box, and content controls useful for some text labels next to some of the fields. Just enough to set a non login indescribable, but certainly not enough to make the environment unpleasant bluish in the logon page standard SharePoint (see Figure 1 again). The login page is based on the home page in the _layouts folder simple.master define most of the look you see around the page (see Figure 2). What follows is the Page directive at the top of the login.aspx page that shows the association of the simple.master with page.

Code Snippet

1. <%@ Page Language="C#"
2.     Inherits="Microsoft.SharePoint.ApplicationPages.LoginPage"
3.     MasterPageFile="~/_layouts/simple.master"%>

When you are considering changing the appearance of the access method, you must determine exactly what we are trying to achieve. If you want to change the brand around the form itself, then you need to edit the page simple.master. To change the shape of the connection itself, reordering checks, add additional help text, graphics, etc, then you need to edit the login.aspx page.


Figure 2 – simple.master from the layouts folder

Editing the simple.master page

Like most master pages, the simple.master controls the look and feel or more than just a single page. In fact, it controls the look and feel of seven pages in the _layouts folder:

Page Name	Description
AccessDenied.aspx	Displays a notice that you have been denied access to the requested resource. Shows the name of the currently logged-in user and a link to sign-in as a different user.
Confirmation.aspx	Displays a message indicating that the requested operation succeeded.
Error.aspx	Displays a message indicating that an error has occurred. May also display additional stack trace information if the site has been configured to do so.
Login.aspx	Display a login page allowing users to enter forms authentication credentials.
ReqAcc.aspx	Displays a notice that you have been denied access to the requested resource.
Signout.aspx	Responsible for logging a user out of the site.
Webdeleted.aspx	Displays a message indicating the web site has been deleted.

People who visit your SharePoint site authenticated forms shall be implemented within a couple of these pages on a regular basis, so you'll definitely want to include in any effort simple.master brand who are committed to your SharePoint site. However, with seven different pages based on page simple.master, the question is what can be changed on page simple.master and what to leave? ContentPlaceHolders Master pages contain controls that identify the sections of the page where the content can be injected by a content page. Content pages contain content controls that relate to the ContentPlaceHolder controls on the master. If a content page refers to a ContentPlaceHolder in the master, but you have taken that ContentPlaceHolder, it fails. Therefore, the key to the modification of a homepage is not necessary to remove any ContentPlaceHolder control.

ContentPlaceHolder controls Determinging exactly what is needed in a home can be very difficult because some of ContentPlaceHolders may be required by a page, but not in another. For example, the page contains a ContentPlaceHolder controls simple.master name PlaceHolderPageImage. If the simple.master, login.aspx the page loads without any problem because the login.aspx page does not refer to the control. However, you get an error when you hit the AccessDenied.aspx page because PlaceHolderPageImage used to insert a small icon on the page. From simple.master only controls the appearance of seven pages, which do not have much time to review each page to see if it has taken a necessary control. With the main pages of others who are not so fortunate. APPLICATION
One way to avoid the headache of accidentally removing the controls required is to leave them on the page, but hide them. The process looks something like this:
1. Open your master page file
2. At the bottom of the page, add a hidden panel using the following code:

Code Snippet

1. <asp:Panel runat="server" visible="false">
2.  </asp:Panel>

3. Look through the markup of your content page and locate any ContentPlaceHolder controls  (or any other server controls for that matter) on the master page
4. When you find a ContentPlaceHolder control (or a server control) cut and paste it into that hidden panel

When finished, have a home server controls which are entirely contained in a hidden panel. View any page that references that I love, and you will see that the page is rendered without any error, because all the controls that are not originally there, just hidden. Of course, also is without any type of content, because the hidden panel hides everything, but we'll take care of that next. Now you can start changing the look of the homepage by adding brand elements to your corporate image. In doing so, you can start adding back in any ContentPlaceHolders and server controls you want in the final home.

If you’re curious, the following ContentPlaceHolders are required in the simple.master:

· PlaceHolderAdditionalPageHead
· PlaceHolderPageTitle
· PlaceHolderSiteName
· PlaceHolderTopNavBar
· PlaceHolderTitleBreadcrumb
· PlaceHolderPageImage
· PlaceHolderPageTitleInTitleArea
· PlaceHolderMain
· PlaceHolderPageDescription
You’ll also probably want to keep the ScriptLinkControl named ScriptLink1 as well, because it contains important JavaScript includes.

 

Editing the login page

Editing a page of content is a task far less dangerous than changing a page, because any error introduced is located on the page itself. You can save a copy of the page on your browser and refresh the screen to make a change to see if it breaks. Like the homepage, the most important thing to remember in a content page is the class that controls the page is in search of specific page elements. If it comes to finding a page element is not there, the page throws an error and would not be. If you do not want an item to display on the screen, you can place the control on a hidden control panel to hide it from view without breaking the code that handles the page.

Most changes will be doing in the content pages are cosmetic, and is likely to revolve around adding additional content here and there and change the design of elements within the page. Understand, however, that all these SharePoint pages are built using ASP. NET. As such, these pages can be altered in any way you can customize an ASP.NET page, allowing you to do some heavy renovations if desired. For example, take the login.aspx page. Here is the Page directive in login.aspx:

Code Snippet

1. <%@ Page Language="C#"
2.          Inherits="Microsoft.SharePoint.ApplicationPages.LoginPage"
3. MasterPageFile="~/_layouts/simple.master" %>

Note that references simple.master page as your home page and inherits its functionality Microsoft.SharePoint.ApplicationPages.LoginPage class. If you do not want the page to use a login.aspx page, you can remove the MasterPageFile element in the Page directive and place all the marks of marked directly in the login.aspx page itself. I do not recommend the approach, but you can do. Or what if you do not like the way Microsoft.SharePoint.ApplicationPages.LoginPage class is responsible for the page? You can remove the item to remove the logic of the page completely, or the point that in a different class. Removing the element inherits, you can write your own custom code for the page by adding server-side script directly in the login.aspx page. I put the following code in my login.aspx page and works well (and he really register on the site too!)

Code Snippet

1. <%@ Page Language="C#" %>
2.     <script runat="server">
3.         protected override void OnLoad(EventArgs e)
4.         {
5.             Response.Write("This is from the onload event");
6.             base.OnLoad(e);
7.         }
8.     </script>
9.     <html>
10.          <body>
11.              <form runat="server">
12.                  <asp:login id="login" runat="server" />
13.              </form>
14.          </body>
15.     </html>

Is it a good idea to get rid of the homepage and the control class for a SharePoint page? Absolutely not! But it does show that the flexibility is in editing pages.