All posts in Development

Handling REST Responses in SharePoint Designer Workflows – Reading The Response

Years ago when Microsoft released it’s latest version of SharePoint Designer, it came with a few enhancements that really made building workflows with Designer more robust and efficient.  One efficiency enhancement was the ability to copy actions, steps and even entire stages within the same workflow or even between workflows.  Microsoft also allowed for the ability to move back and forth between stages instead of continuing down a parallel path (called a state machine workflow).  While the addition of state machine workflows to Designer (previously only available in Visual Studio workflows) is great; in my opinion the best (by a very small margin) addition to Designer is the ability to call web services.  As your queries get more and more complex however, knowing what is coming back into the workflow can be filled with frustration as you try to determine how to get the data from the response content.  While I it isn’t a new concept, I wanted to discuss handling REST responses in SharePoint Designer workflows.  Or at least how I do it.  The method I use is pretty straight forward and very easy to implement.

Read more

SharePoint Custom Solution Crashes IIS Worker Process (w3wp.exe) – Part 2

In Part 1 of this series, I discussed an issue we were having in one of our SharePoint 2013 farms and how I determined the issue was occurring because of a set of event receivers acting on the library.  In this post, I will discuss the code being used and what the final result was determined to be.  Stick around, it’s not what you think.

To be terribly honest nothing jumped out at me while looking over the code.  The initial review of the code indicated the issue could be around where the event receiver was trying to determine if the user adding the file was a member of the site owner group.  The original code was:

private void ProcessItemIfAuthorized(SPItemEventProperties properties, string errorMessage, bool isItemAdding)
{
    bool isFile;
    bool isSiteOwner = false;

    //Get the list of groups user is a part of.  Find if a part of site Owners
    SPSecurityManager secMgr = new SPSecurityManager();            
    List<string> spGroupsInWeb = secMgr.GetSPGroupsInWeb(properties.Web);

    //Loop through each group in the web.  If the group is the owner group, check to see if user exists within.
    foreach(string spGroup in spGroupsInWeb)
    {
        if(spGroup.Contains("<NAME OF OWNER GROUP>"))
        {
            isSiteOwner = secMgr.CheckIfUserInSPGroup(properties.Web, spGroup, secMgr.ParseUserIDFromClaim(properties.UserLoginName));
        }
    }

This seems pretty straight forward, but when “CheckIfUserInSPGroup” is called things aren’t quite as kosher.

public bool CheckIfUserInSPGroup(SPWeb spWeb, string groupUserName, string userName)
{
    bool maxReached = false;
    bool existsInGroup = false;

    if (!existsInGroup)
    {
        SPSecurity.RunWithElevatedPrivileges(delegate()
        {
            using (SPSite spSite = new SPSite(spWeb.Site.ID))
            {
                using (SPWeb currentWeb = spSite.OpenWeb(spWeb.ID))
                {
                    foreach (SPPrincipalInfo accountInfo in SPUtility.GetPrincipalsInGroup(currentWeb, groupUserName, int.MaxValue - 1, out maxReached))
                    {
                        //check to see if the account we are looking at is a nested group.  If so call the function again to dig deeper.
                        if (accountInfo.PrincipalType == SPPrincipalType.SecurityGroup)
                        {
                            existsInGroup = this.CheckIfUserInSPGroup(spWeb, accountInfo.LoginName, userName);

                            if (existsInGroup)
                            {
                                break;
                            }
                        }
                        else
                        {
                            if (this.ParseUserIDFromClaim(accountInfo.LoginName) == userName)
                            {
                                existsInGroup = true;
                                break;
                            }
                        }
                    }
                }
            }
        });

Again, normally not a huge issue, except that best practices state that you shouldn’t instantiate SPSite, SPWeb or SPList objects within an Event Receiver.  The reason for this is it causes extra database calls (more information here: https://msdn.microsoft.com/en-us/library/office/ee724407(v=office.14).aspx).  I thought this could be the culprit, but wasn’t convinced.  If this was the issue, why does it work fine for years and then suddenly stop working?  The reason the code is instantiating the SPSite and SPWeb object is it is used elsewhere in the solution and could be called by users who do not have the required access.  The same goes for the event receiver.  If I do not have access to control security groups in the site, I get an UnauthorizedAccessException.

So I thought, why not just use that.  We can safely assume that if the UnauthorizedAccessException error is thrown, the user is not in the Owners group.  So I updated the code with a try\catch (why one wasn’t already being used I don’t know) and added some logic into the catch.  Not generally the best method, but when used for targeted exceptions I believe acceptable IMHO.

//Loop through each group in the web.  If the group is the owner group, check to see if user exists within.
foreach(string spGroup in spGroupsInWeb)
{
    if(spGroup.Contains("<NAME OF OWNER GROUP>"))
    {
        try
        {
            isSiteOwner = secMgr.CheckIfUserInSPGroupEvntRcvr(properties.Web, spGroup, secMgr.ParseUserIDFromClaim(properties.UserLoginName));                        
        }
        //If authorization exception is fired, then we can assume the user is NOT in the owners group
        catch(UnauthorizedAccessException exNotAuthorized)
        {
            SPDiagnosticsService.Local.WriteTrace
                (
                    0,
                    new SPDiagnosticsCategory("App Security", TraceSeverity.High, EventSeverity.ErrorCritical),
                    TraceSeverity.High,
                    exNotAuthorized.ToString(),
                    string.Empty
                );

            isSiteOwner = false;
        }
        catch(Exception ex)
        {
            SPDiagnosticsService.Local.WriteTrace
                (
                    0,
                    new SPDiagnosticsCategory("App Security", TraceSeverity.High, EventSeverity.ErrorCritical),
                    TraceSeverity.High,
                    ex.ToString(),
                    string.Empty
                );

            //have to assume they don't have necassary access so files aren't added or deleted upon error
            isSiteOwner = false;
        }
    }
}

I also created a new method for the event receiver to call.  I couldn’t modify the existing one, as it contained valid logic to handle users without access and was being used elsewhere.

        public bool CheckIfUserInSPGroupEvntRcvr(SPWeb spWeb, string groupUserName, string userName)
        {
            bool maxReached = false;
            bool existsInGroup = false;

            if (!existsInGroup)
            {
                foreach (SPPrincipalInfo accountInfo in SPUtility.GetPrincipalsInGroup(spWeb, groupUserName, int.MaxValue - 1, out maxReached))
                {
                    //check to see if the account we are looking at is a nested group.  If so call the function again to dig deeper.
                    if (accountInfo.PrincipalType == SPPrincipalType.SecurityGroup)
                    {
                        existsInGroup = this.CheckIfUserInSPGroupEvntRcvr(spWeb, accountInfo.LoginName, userName);

                        if (existsInGroup)
                        {
                            break;
                        }
                    }
                    else
                    {
                        if (this.ParseUserIDFromClaim(accountInfo.LoginName) == userName)
                        {
                            existsInGroup = true;
                            break;
                        }
                    }
                }
            }

            return existsInGroup;
        }

So I moved the code into Pre-Prod and tried it out.  No change.  Still hanging, throwing errors and crashing the app pool.

Next step was to install Visual Studio into Pre-Prod and attach to the IIS Worker process.  I followed the code until it got into the newly created CheckIfUserInSPGroupEvntRcvr method.  There it stayed.  It kept looping through the AD users and groups within the SharePoint group.  As it was looping I watched the worker process memory usage grow and grow until it finally crashed again.  This didn’t make any sense as there are NOT that many users in these groups.

The Cause of it All

I took a look at the ownership group for the site I was testing with.  Like most (not all) of our project sites, it contained an AD group that contains our project team.  Let’s call that group All-Project.  All-Project had about a dozen users within it, however, there was an anomaly.  It also contained the Owners group from another project site.  This was an oddity.  I took a look at the Owner group and it also contained the same All-Project group. There was the culprit.

As you can see in the code above, it is designed for nested groups, so if the code hits a group it digs down to see if the nested group contains the user.  Because this Owner group was added (in error I found out while trying to figure out why it was there) to the All-Projects group, the code would dig into All-Projects then to the Owners group, from there back into the All-Projects group and then back into the Owners group… see where I am going with this?  By adding that single group to the All-Projects group in error an infinite recursion loop was created in the code.

The Final Fix

So the final fix was not an environmental change or a code modification.  It was simply to remove the Owners group from the All-Projects group.  Once that was done, the original code functioned as designed.  If this becomes a regular occurrence I will have to update the code to handle such an event, but in this case, I didn’t.  The farm is in containment (no further development short of break\fix) and the issue has not occurred for two years before this.  I hope the steps I documented in this blog series helps others out.

 

Thanks for reading!

Fake a Required Field on a SharePoint List Form

As with so many things I write about recently I had a need to do something different at my client site.  This time I needed to fake a required field on a SharePoint list form.  The reason behind it was we had customized the form and had some fields that were required in some cases, but not all.  These fields could not be marked as required in the content type because then we would need to fill in default or bogus data into the fields and that wouldn’t look good so I decided to simply make the fields look exactly like a SharePoint required field without actually setting them up that way.

Fake a Required Field on a SharePoint List Form

This may already be documented somewhere, but I didn’t bother to look.  I thought the solution I came up with is pretty quick and clean so I wanted to share it.  I am basically just inserting the same <span> field that SharePoint does onto a label when the field is set as a required field.  Using JQuery I get the <nobr> control and then insert the <span> after.  Here’s the code to accomplish that:

/********************************************************************************************
*Function Name: displayAsRequired                 											*
*Parameters: $fieldTitle - Title of the field                								*
*Purpose: Makes a control appear as if it were required, without making it required in SP   *
/********************************************************************************************/
function displayAsRequired(fieldTitle) {
    var reqField = $(".ms-formlabel nobr").filter(function (){
        return $(this).contents().eq(0).text() === fieldTitle;
    }).after("<span title='This is a required field.' class='ms-accentText'> *</span>");
}

So you just need to pass in the field name (display name, not the internal name) to the function.  The code will find the corresponding <nobr> control on the form and update it to look like a required field.  Kudos to a comment Marc Anderson made in a blog somewhere about accessing the <nobr> field.  I would have done it a bit differently, but I liked the flow of the code in the comment he made.

Thanks for reading!!

Getting User Data from People Picker with JavaScript

Back in the SOM (Server Object Model) days it was pretty straight forward and well documented how to gather a user’s information from within a SharePoint form, or even go out and get it from SharePoint itself having just a single piece of information like email, login name or even just the user’s first and last name.  While there are techniques to doing this from the client side using CSOM (Client Side Object Model) or REST APIs what if you didn’t need ALL the user’s information and just needed a few important parts of it.  If the form you are working in has a people picker then you are all set.  Today I am going to show you all about getting user data from People Picker with JavaScript.

Read more

Playing Further Outside Your Sandbox: Advanced Concepts in SharePoint BCS – Slide Deck

Hi everyone,

On October 20, 2016 I had the honour of taking part in the Collab365 Global Conference.  At this conference I presented my session on Advanced Concepts in SharePoint BCS.  I forgot to provide the slide deck to the Collab365 team prior to the conference.  I have posted the slide deck here.

Playing Further Outside Your Sandbox: Advanced Concepts in SharePoint BCS slide deck.