I’ve been toying around with sharepoint 2010 for awhile and I always find myself deploying the following changes to the provided site collections web.config.

Script Block Ready MasterPages

Deploying script-enabled master pages for customized look-and-feel is a must for me. Below will allow any masterpage uploaded to _catalogs/masterpage to include script blocks.

<PageParserPaths>
	<PageParserPath VirtualPath="/_catalogs/masterpage/*" CompilationMode="Always" AllowServerSideScript="true" IncludeSubFolders="true" />
</PageParserPaths>

Custom RoleProvider & MembershipProvider Wildcards

Implementing your own RoleProvider and/or MembershipProvider you may want to enable your provider to search via wildcard otherwise the people picker may not work as you expect it.

<PeoplePickerWildcards>
  <clear />
  <add key="AspNetSqlMembershipProvider" value="%" />
  <add key="MyMembershipProvider" value="%" />
</PeoplePickerWildcards>

.NET 3.5 Assemblies

Out-of-box SharePoint 2010 isn’t including some assemblies you may be referencing in your pages (script blocks). To take care of this go ahead and add the below in.

<compilation batch="false" debug="false">
<assemblies>
<add assembly="System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
<add assembly="System.Data.DataSetExtensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
<add assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
<add assembly="System.Xml.Linq, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
<add assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
<add assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<add assembly="Microsoft.Web.CommandUI, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
<add assembly="Microsoft.SharePoint.Search, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
<add assembly="Microsoft.Office.Access.Server.UI, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
<add assembly="Microsoft.SharePoint.Publishing, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
</assemblies>

Adding “Var” Support to A SharePoint 2010 Site

Tack on the below snippet of configuration goo and you’ll enable pages to use var syntax in your webparts (more like ASP.NET MVC).

<system.codedom>
<compilers>
  <compiler language="c#;cs;csharp" extension=".cs" warningLevel="4" type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
    <providerOption name="CompilerVersion" value="v3.5" />
    <providerOption name="WarnAsError" value="false" />
  </compiler>
</compilers>
</system.codedom>

Working with Permission Levels

Reference Document

SPUser and SPWeb Basics

The WSS object model represents external security principals using SPUser objects. You can retrieve the SPUser object for the current user through the current SPWeb object:

Out-Of-Box Roles

A permission level is a named set of permissions that is defined within the scope of a site. WSS includes four built-in permission levels: Read, Contribute, Design, and Full Access. If you need greater granularity than this, you can create your own custom permission levels using the WSS object model or through the standard WSS administrative pages that are accessible to the site collection owner.

SPWeb site = SPContext.Current.Web;
SPUser user = site.CurrentUser;
string DisplayName = user.Name;
string Login = user.LoginName;
string EMail = user.Email;
string User Notes = user.Notes;

The SPUser object exposes properties of an external security principal, such as login name, display name, and e-mail address. These properties are usually retrieved from an underlying user repository, such as an Active Directory domain, when the external principal is added to a site. The SPUser object also exposes properties that track WSS-specific metadata, such as the Notes field.

WSS maintains the profile data for external users, groups, and roles in a hidden list, which is known as the User Information List. Every time WSS provisions a new site collection, it automatically creates the User Information List as a hidden list in the top-level site. WSS then adds a new profile for each external principal the first time that principal is assigned permission or the first time it passes a security check to access a securable object. Note that the user profile stored in the User Information List does not extend across site collections—when users update their profile settings in one site collection, there are no changes to that user’s profile settings in other site collections.

Users and Groups in SharePoint

Another potential source of confusion is that SPUser objects do not always represent actual users. SPUser objects can also represent Active Directory groups and ASP.NET roles. WSS tracks a profile for each of these external principal types in the User Information List along with the profile data for external users.
Many of the programmatic aspects of the SharePoint security model are exposed at the site level through SPWeb objects. This is the case if you want to discover which users are members of the current site. An SPWeb object exposes three different collections of users, as shown in this code fragment:

SPWeb site = SPContext.Current.Web;
SPUserCollection c1 = site.Users;
SPUserCollection c2 = site.AllUsers;
SPUserCollection c3 = site.SiteUsers;

The Users collection has the smallest membership of these three collections. This collection includes all the external principals that have been explicitly assigned permissions within the current site.

The AllUsers collection includes all members of the Users collection, plus external users that have accessed objects within the site using implicit permissions through group or role membership. For example, imagine a user named Brian with the login of LITWAREINC\BrianC that has never been given explicit permissions to access a site and view a particular list. However, he might still be able to view the list because of his membership within an Active Directory group that has been configured with list view permissions. When Brian first accesses the site or one of its objects (say, a list using implicit permissions), he is added as a member of the AllUsers collection, but he is not added as a member of the Users collection.

The SiteUsers collection is an aggregation that combines membership for each AllUsers collection within the current site collection. The membership of this collection includes all external principals that have been assigned permissions to any object within the site collection as well as all external users that have been granted access to any of the site collection’s objects using implicit permissions.

Permissions in SharePoint

A permission level is a named set of permissions that is defined within the scope of a site. WSS includes four built-in permission levels: Read, Contribute, Design, and Full Access. If you need greater granularity than this, you can create your own custom permission levels using the WSS object model or through the standard WSS administrative pages that are accessible to the site collection owner.

Permission levels are sometimes called roles, and they are represented in the WSS object model using SPRoleDefinition objects. You can assign a permission level to an external user or groups using a SPRoleAssignment object. For example, here I assign the built-in Contribute permission level to the Windows user with a login name of LITWAREINC\BrianC:

SPWeb site = SPContext.Current.Web;
SPRoleDefinition role = site.RoleDefinitions["Contribute"];
SPRoleAssignment roleAssignment;
roleAssignment = new SPRoleAssignment(@"LITWAREINC\BrianC",
                                       "brianc@litwareinc.com",
                                       "Brian Cox",
                                       "Notes about Brian Cox");

roleAssignment.RoleDefinitionBindings.Add(role);
site.RoleAssignments.Add(roleAssignment);

This technique makes it unnecessary to add the user to one of the SPUser collections since that is done automatically by WSS when an external user or group is assigned a permission for the first time within a site. The code you’ve just seen will create a user profile in the User Information List if one does not exist, and it will also add the user as a member of the current site’s Users collection.

Quick little example of showing all entities in BCS. Shows off some abilities to gain access to these objects from within your sharepoint instance.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<%@ Page Language="C#" %>
<%@ Import Namespace="Microsoft.SharePoint.BusinessData.SharedService"%>
<%@ Import Namespace="Microsoft.BusinessData.MetadataModel"%>
<%@ Import Namespace="Microsoft.BusinessData.Runtime"%>
<%@ Import Namespace="Microsoft.SharePoint.Administration"%>
<%@ Import Namespace="Microsoft.SharePoint"%>
<%@ Import Namespace="System.Collections.Generic"%>
<%@ Import Namespace="System.Diagnostics"%>
<%@ Import Namespace="System.Linq"%>
<script type="text/C#" runat="server">
    protected void Page_Load(object sender, EventArgs e)
    {
        try
        {
            using (var site = SPContext.Current.Site)
            {
                using (new SPServiceContextScope(SPServiceContext.GetContext(site)))
                {
                    BdcService service = SPFarm.Local.Services.GetValue<BdcService>(String.Empty);
                    var catalog = service.GetDatabaseBackedMetadataCatalog(SPServiceContext.Current);

                    List<IEntity> list = new List<IEntity>();
                    foreach (var i in catalog.GetEntities("*")) {
                        list.Add(i);
                    }

                    var ds = (from obj in list
                              let methods = obj.GetMethodInstances()
                              let properties = obj.GetProperties()
                              select new
                              {
                                  Name = obj.Name,
                                  Namespace = obj.Namespace,
                                  Methods = (from item in methods select item.Key).ToList(),
                                  Properties = (from item in properties select item.Key).ToList(),
                              }).ToList();

                    rptr.DataSource = ds;
                    rptr.DataBind();
                }
            }
        }
        catch (Exception ex)
        {
            Response.Write(ex.ToString());
        }
    }
</script>
<html dir="ltr" xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
<meta name="WebPartPageExpansion" content="full" />
</head>
<body>

<asp:Repeater runat="server" id="rptr">
<HeaderTemplate>
<table style="width: 100%;">
    <tr>
        <th style="text-align: left;">namespace</th>
        <th style="text-align: left;">entity</th>
        <th style="text-align: left;">properties</th>
        <th style="text-align: left;">methods</th>
    </tr>
</HeaderTemplate>
<ItemTemplate>
<tr>
    <td style="text-align: left;"><%# Eval("Namespace") %></td>
	<td style="text-align: left;"><%# Eval("Name") %></td>
	<td style="text-align: left;"><%# String.Join("<br/>", (Eval("Properties") as IList<string>).ToArray()) %></td>
	<td style="text-align: left;"><%# String.Join("<br/>", (Eval("Methods") as IList<string>).ToArray())%></td>
</tr>
</ItemTemplate>
<FooterTemplate>
</table>
</FooterTemplate>
</asp:Repeater>

</body>
</html>