I'm the author of open source claims provider LDAPCP (https://ldapcp.codeplex.com/) and I recently discovered a very important design constraint that causes serious issues if ignored:
Claims providers are mostly called by static class SPClaimProviderOperations (actually I think it's the only class that can call them).
This class and its methods are static, which implies that every thread will share the same instance of the claims provider class.
As a consequence, the claims provider itself must absolutely be thread safe, and its critical variables (the ones that store results) must be unique to the current thread, otherwise a thread may alter the result of another thread, and a user might get permissions/claims of another user.

To ensure thread safety, you need locks.
Regarding uniqueness of variables, since 1 instance of the claims provider is shared with multiple threads, variables of the class are also shared (they are allocated in the managed heap).
To illustrate this point, I created this small console application that simulates how SPClaimProviderOperations calls custom claims providers:

using System;
using System.Collections.ObjectModel;
using System.Threading;

namespace LDAPCP_2013_Console
{
    public static class Program
    {
        static void Main(string[] args)
        {
            for (int i = 0; i < 5; i++)
            {
                Thread oThread = new Thread(new ThreadStart(FakeSPClaimProviderOperations.CallFillResolve));
                oThread.Start();
            }
            Console.ReadLine();
        }
    }

    public static class FakeSPClaimProviderOperations
    {
        static FakeCustomClaimProvider cp;
        public static void CallFillResolve()
        {
            if (cp == null) cp = new FakeCustomClaimProvider();
            cp.FillResolve();
        }
    }

    public class FakeCustomClaimProvider
    {
        // Collection shared by every thread
        Collection<String> MyCollectionClass = new Collection<string>();

        public void FillResolve()
        {
            // Collection unique to current thread
            Collection<String> MyCollectionMethod = new Collection<string>();

            MyCollectionMethod.Add("item1");
            MyCollectionClass.Add("item1");

            Console.WriteLine(String.Format("MyCollectionMethod has {0} items.", MyCollectionMethod.Count.ToString()));
            Console.WriteLine(String.Format("MyCollectionClass has {0} items.\r\n", MyCollectionClass.Count.ToString()));
        }
    }
}

Output:
MyCollectionMethod has 1 items.
MyCollectionClass has 1 items.

MyCollectionMethod has 1 items.
MyCollectionClass has 2 items.

MyCollectionMethod has 1 items.
MyCollectionClass has 3 items.

MyCollectionMethod has 1 items.
MyCollectionClass has 4 items.

MyCollectionMethod has 1 items.
MyCollectionClass has 5 items.

To conclude, ensuring thread safety and isolation of variables is absolutely essential in custom claims providers, otherwise random permissions issues may occur and they are very difficult to track down.

Well, there are good reasons to explain this: since users authenticate in an external STS, SharePoint cannot assume if the users authenticated within the organization, or outside, and it also doesn’t know if users authenticated in a LDAP or in a totally different login system such as a SQL DB.

Fortunately, SharePoint gives the possibility for developers to  create a claim provider that implements this, and I recently published mine on codeplex: https://ldapcp.codeplex.com/. It integrates easily with existing environments, does not mess up anything and is available for free with the source code!

Let’s say you want to display search results in a page. To do so you can use the QueryEx method of the search.asmx web service. This method takes 1 parameter, queryXml, which is an XML representation of a query.

To create the datasource, you click on Data Sources > SOAP Service Connection (in the ribbon). This window appears:

In the Service description location field, type the URL of the search web service. For example: https://yvandev10:6000/_vti_bin/search.asmx?WSDL and click “Connect Now”.

In the parameters, queryXml attribute appears so you can set its value by clicking on “Modify”.

Normally, queryXml looks like the following:

<QueryPacket xmlns="urn:Microsoft.Search.Query" Revision="1000">
<Query domain="QDomain">
<SupportedFormats>
<Format>urn:Microsoft.Search.Response.Document.Document</Format>
</SupportedFormats>
<Context>
<QueryText language="en-US" type="MSSQLFT">SELECT Title, Path, Description, Write, Rank, Size FROM Scope() WHERE CONTAINS(Description, 'SharePoint') AND "Scope" = 'All Sites'</QueryText>
</Context>
<Range><StartAt>1</StartAt><Count>20</Count></Range>
<EnableStemming>false</EnableStemming>
<TrimDuplicates>true</TrimDuplicates>
<IgnoreAllNoiseQuery>true</IgnoreAllNoiseQuery>
<ImplicitAndBehavior>true</ImplicitAndBehavior>
<IncludeRelevanceResults>true</IncludeRelevanceResults>
<IncludeSpecialTermResults>true</IncludeSpecialTermResults>
<IncludeHighConfidenceResults>true</IncludeHighConfidenceResults>
</Query>
</QueryPacket>

But there is a trick to use it in SharePoint Designer: you have to encode XML special character, and put the whole query in 1 line. So it results in the following:

&lt;QueryPacket xmlns=&quot;urn:Microsoft.Search.Query&quot; Revision=&quot;1000&quot;&gt; &lt;Query domain=&quot;QDomain&quot;&gt; &lt;SupportedFormats&gt; &lt;Format&gt;urn:Microsoft.Search.Response.Document.Document&lt;/Format&gt; &lt;/SupportedFormats&gt; &lt;Context&gt; &lt;QueryText language=&quot;en-US&quot; type=&quot;MSSQLFT&quot;&gt;SELECT Title, Path, Description, Write, Rank, Size FROM Scope() WHERE CONTAINS(Description, 'SharePoint') AND &quot;Scope&quot; = 'All Sites'&lt;/QueryText&gt; &lt;/Context&gt; &lt;Range&gt;&lt;StartAt&gt;1&lt;/StartAt&gt;&lt;Count&gt;20&lt;/Count&gt;&lt;/Range&gt; &lt;EnableStemming&gt;false&lt;/EnableStemming&gt; &lt;TrimDuplicates&gt;true&lt;/TrimDuplicates&gt; &lt;IgnoreAllNoiseQuery&gt;true&lt;/IgnoreAllNoiseQuery&gt; &lt;ImplicitAndBehavior&gt;true&lt;/ImplicitAndBehavior&gt; &lt;IncludeRelevanceResults&gt;true&lt;/IncludeRelevanceResults&gt; &lt;IncludeSpecialTermResults&gt;true&lt;/IncludeSpecialTermResults&gt; &lt;IncludeHighConfidenceResults&gt;true&lt;/IncludeHighConfidenceResults&gt; &lt;/Query&gt; &lt;/QueryPacket&gt;

that you can type in the queryXml value:

A list of special characters and their encoded value can be found in this article: https://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references.
Notepad++ is a good tool to encode string quickly: select the string > TextFX > TextFX Convert > Encore HTML (&<>”).

Finally, you can use the data source in a page through a DataView control. If connection to web service was successful

• you’ll see the DataSource properties in the properties tab
• With Fiddler, while you add the DataView control, a bunch of calls to /_vti_bin/webpartpages.asmx, all resulting in a HTTP 200 (perhaps HTTP 401 before – expected) responses.

If you get an HTTP 500 response instead, the queryXml value is likely not set correctly.

Under certain condition, you may see this error message when you try to start the FIM Synchronization Service:

UserProfileApplication.SynchronizeMIIS: Failed to configure ILM, will attempt during next rerun. Exception: System.Security.SecurityException: There are currently no logon servers available to service the logon request. at System.Security.Principal.WindowsIdentity.KerbS4ULogon(String upn) at
System.Security.Principal.WindowsIdentity..ctor(String sUserPrincipalName, String type) at System.Security.Principal.WindowsIdentity..ctor(String sUserPrincipalName) at Microsoft.IdentityManagement.SetupUtils.IlmWSSetup.GetDomainAccountSIDHexString(String domainName, String accountName) at
Microsoft.IdentityManagement.SetupUtils.IlmWSSetup.GrantSQLRightsToServiceAccount() at Microsoft.IdentityManagement.SetupUtils.IlmWSSetup.IlmBuildDatabase() at Microsoft.Office.Server.UserProfiles.Synchronization.ILMPostSetupConfiguration.ConfigureIlmWebService(Boolean existingDatabase) at
Microsoft.Office.Server.Administration.UserProfileApplication.SetupSynchronizationService(ProfileSynchronizationServiceInstance profileSyncInstance) The Zone of the assembly that failed was: MyComputer.

Cause

The reason is related to Kerberos and is a little bit difficult to explain (as always with Kerberos !). I try to make the most simple possible:

OWSTIMER process tries to get a service ticket for itself (a TGS with Sname/SPN = the OWSTIMER account) that contains information about itself (this is called S4U2Self).

However, a security feature introduced in Windows Server 2003 prevents the KDC to distribute a TGS for an account that does not have a SPN defined, as explained in this technet article (https://technet.microsoft.com/fr-fr/library/cc772815(WS.10).aspx):

“Additionally, in Windows Server 2003, KDCs will not issue a service ticket for an account that does not have an SPN. If a service account were simply a user account with a human-generated password, then that account would be more vulnerable to an offline dictionary attack. For an account without an SPN, the KDC will return KDC_ERR_S_PRINCIPAL_UNKNOWN. However, the context of the error will be KRB_ERR_MUST_USE_USER2USER, which has the description of "Server principal valid for user-to-user only.""”

Resolution

It is very easy to fix, all you need is to add a fake SPN, whatever it is, to the OWSTimer account, so that KDC will allow to distribute a ticket for that account. For example:

setspn –a NONE/NONE OWSTimerAccount

Then you can successfully start your service !

In most scenarios this does not have any impact, but some companies don’t use the MySite and in such a case redirection needs to be deactivated.

Fortunately, it’s very easy to deactivate the redirection by writing a feature that will prevent controls which redirect to be rendered. This can be done using Delegate Controls, which are described in this article.

feature.xml :

<?xml version="1.0" encoding="utf-8"?>
<Feature
  Id="6630E84A-F21D-4c9d-BA71-CDB7785E0787"
  Title="Yvand.BypassMysite"
  Description="Display user details in userdisp.aspx page within the site collection, as per pre-SP2 behavior."
  Creator="Yvan Duhamel"
  Version="1.0.0.0"
  Scope="Farm"
  Hidden="FALSE"
  xmlns="https://schemas.microsoft.com/sharepoint/">
  <ElementManifests>
    <ElementManifest Location="MySiteFeatureElements.xml" />
  </ElementManifests>
</Feature>

MySiteFeatureElements.xml :

<Elements xmlns="https://schemas.microsoft.com/sharepoint/">
    <Control Id="GlobalSiteLink1" Sequence="50" ControlSrc="" />
    <Control Id="GlobalSiteLink2" Sequence="50" ControlSrc=""/>
    <Control Id="ProfileRedirection" Sequence="50" ControlSrc=""/>
</Elements>

Once the feature is installed, it can be activated at farm level (Central Administration > Operations > Manage Farm Features) to immediately deactivate the redirection to MySite.

SharePoint workflow functionality comes with a set of specific activities and events to leverage SharePoint specific actions.

One of them is OnWorkflowItemChanged, designed to fire when item which started the workflow was modified.

The Problem

However, this event causes an unexpected behavior that locks the workflow instance in the content database for a while when item is modified.

Let’s check the following simple workflow:

Basically, it creates a task, wait for the task to be modified and then simply terminates.

Notice the OnWorkflowItemChanged event handler is in a branch that is always false (condition is ‘1 == 2’), so it should never be processed.

Now imagine this scenario :

1) you create a new item so that your workflow instance starts

2) After workflow instance has started, you edit the item.

3) You edit the task

This action should wake up the workflow that would delete the task and terminate.

However, because of OnWorkflowItemChanged event, the workflow will be locked at step 2 (as soon as you edit the item). So you must wait for a while (impossible to reduce) before it can be waked up by OWSTIMER and resumes.

A side effect you may notice is this error message you will get if you try to edit the task:
“This task is currently locked by a running workflow and cannot be edited.”

How to fix it

1) If you wait long enough, workflow should always resume in the OWSTimer.

2) You can modify a little bit the design of the workflow to workaround this problem:

Take a look at the same workflow with a few modifications (I removed the if condition because it was only to illustrate the problem):

Here are the modifications to make it working:

1. Add a SequenceActivity and move OnWorkflowItemChanged event inside.
2. Add an InitializeWorkflow Activity inside the SequenceActivity
3. Create a new correlation token in the InitializeWorkflow and set the OwnerActivityName to the SequenceActivity
4. Use this new token in the OnWorkflowItemChanged

These few modifications make your workflow running fine, and it is not locked anymore.

Yvan Duhamel, Support Escalation Engineer

Both RichHtmlField control and content editor webpart allow you to write content in SharePoint 2007 more or less with the same experience than you would have with Word.

One good feature is the ability for administrators to create predefined styles that contributors can directly select and apply to their content:

These styles are easy to create and you can find a step by step here.

However, when contributors apply a style to their paragraph, it automatically creates a new “<span>” tag, and applies the style to the “<span>”. This causes several issues:

• Each time you apply a style, it creates a new “<span>” even if it is already in a “<span>”, so you may end up with dozen of “<span>” that inherit from each other
• It makes difficult to play with advanced CSS styling, because you cannot predict how many child “<span>” you will get in your HTML code.
• Some formatting options are not easy to apply to “<span>”, because it is an inline element, contrary to the “<p>” tag that is a block element.

Fortunately, the behavior of “<span>” tags can be modified to act as “<p>” tags, so that it renders as a block and makes possible for administrators to justify text in CSS styles. Below is a style that will allow a “<span>” to justify the text it contains:

.ms-rteCustom-YvandJustifiedText
{
    text-align:justify;
    display:block;
    color: purple;
}

However you should be aware that if you apply this style to a part of the paragraph, this part will behave as a new independent paragraph. In the  sample below, the style was applied only to the text in purple, although the whole text is a single paragraph:

In SharePoint 2010, this behavior was modified and “<span>” tags are no longer created when contributors apply a style to a whole paragraph. Styles apply directly to “<p>” tags instead, which makes by far easier to manage and generates better HML code.

Of course, a “<span>” will still be created if style is applied to a part of a paragraph.

Yvan Duhamel, Support Escalation Engineer.

As a site collection administrator, you use object model to get SPListItem.ForwardLinks in a page that has been propagated in a target site with variations sytem. The page version is at least 1.1.

As a result, you are not able to retrieve SPListItem.ForwardLinks attribute from the current minor version, it returns properties from the last published version (in this scenario 1.0)

Although you are a site collection administrator, you cannot get SPListItem.ForwardLinks properties from the current minor version. This is probably the same behavior with others attributes such as BackwardLinks, but this works fine with title attribute (and probably many others).

To workaround this, you must run your code with elevated privileges to use application pool account. You can find a sample below:

void CheckSPListItemPropertiesAsApppoolAccount(string weburl, string listname)
{
    Result.Text = "";
    Result.Text += "<br/>Running as application pool account";

    SPSecurity.RunWithElevatedPrivileges(delegate()
    {
        using (SPSite site = new SPSite(weburl))
        {
            using (SPWeb web = site.OpenWeb())
            {
                SPList list = web.Lists[listname];
                Result.Text += "<br/><br/>Number of items: " + list.ItemCount.ToString();

                foreach (SPListItem item in list.Items)
                {
                    try
                    {
                        Result.Text += "<br/><br/>Item: " + item.Title;
                        foreach (SPLink link in item.ForwardLinks)
                        {
                            Result.Text += "<br/>URL: " + link.Url;
                        }
                    }
                    catch (Exception e)
                    {
                        Result.Text += "<br/>" + e.Message;
                        Result.Text += "<br/>" + e.StackTrace;
                    }
                }
            }
        }
    });
}

You develop a webpart using AJAX that works fine with SharePoint default masterpage (default.master), but as soon as you use a different masterpage, for example blueband.master, asynchronous postbacks do not work anymore.

The reason is because in those masterpages, SPWebPartManager server tag is outside of <form></form> tags. To workaround this, you can change the location of the ScriptManager tag and put it inside the <form> tag:

<form runat="server" onsubmit="return _spFormOnSubmitWrapper();">
<asp:ScriptManager runat="server" ID="ScriptManager1"></asp:ScriptManager>
<WebPartPages:SPWebPartManager runat="server"/>

Important: if you modify a masterpage provided with SharePoint, such as the blueband.master, you must create a copy of it, modify the copy and update the site to use the new one, don't forget this is not supported to modify SharePoint default files (except a very few ones).

Unfortunately this modification has a major drawback, the page title is broken (it is replaced with "\r\n\t") after the first AJAX postback. Fortunately, it can be fixed very easily with the following piece of code that you can add in your webpart:

It seems SharePoint checks the page title, and set it when it is empty.

If your postbacks are even not working with default masterpage, this article probably does not apply to you, take a look at this kb: https://support.microsoft.com/kb/941955.

You can find general information on AJAX integration with SharePoint and practical example on this page: https://msdn.microsoft.com/en-us/library/bb861881.aspx.

To do this, SharePoint requires that administrator has full permissions on the site collection. This is often the case when we are site collection administrators, but some permission can be removed at web application level, which prevents anyone to activate forms templates (including the setup account)

To solve this, go to Central Administration > Application Management > User Permissions for Web Application, select the web application on which you try to activate your form template and check ALL the boxes.

After validating, you should be able to successfully activate your form template on your site collection.