1

I have a WCF service which is having a service to get sharepoint discussion list items. But it is not returning data. I debug the WCF service and then identified that it is not read inside the list.Folders. But it is getting the spList object, but not go inside listitems by reading folders.

string siteUrl = ConfigurationManager.AppSettings["siturl"];

List<SPDiscussionList> discussionListItems = new List<SPDiscussionList>();
if (!string.IsNullOrEmpty(siteUrl))
{
    SPSecurity.RunWithElevatedPrivileges(delegate()
    {
        using (SPSite spSite = new SPSite(siteUrl))
        {
            spSite.AllowUnsafeUpdates = true;
            using (SPWeb spWeb = spSite.OpenWeb())
            {
                spWeb.AllowUnsafeUpdates = true;
                SPList spList = spWeb.Lists.TryGetList(discussionName);
                if (spList != null)
                {
                    foreach (SPListItem spListItem in spList.Folders)
                    {
                       // DO WORK
                    }
                }
            }
        }
    }
}

DO I have a problem in siteurl Context?

  • I have reformatted the code you posted as best as I can, but it doesn't seem the issue is here unless I am missing something. Can you provide further details? – SPArchaeologist-様 May 17 '16 at 19:05
  • I do not know,my local machine this code is working and go inside the foreach loop.When i deployed this service in to new server it is not working. – KIS May 17 '16 at 19:16
0

You said that the code is working as expected on your local machine but suddenly fails to produce the desired results when you move it to a different server, so even with the incomplete code you posted I would exclude the possibility that your service contains mayor logical errors.

You also stated that on the new server the code reaches the foreach (SPListItem spListItem in spList.Folders) line, but then "fails" at enumerating the discussions items (aka the Folders) on the list. This means that we should be able to safely ignore the missing part in your sample (the "//DO WORK" line) since it is never reached.

Your code is finding the list, but failing to enumerate its item. You also seem performing correct elevation using SPSecurity.RunWithElevatedPrivileges, recreating all the SPWeb and SPSite instances you use inside the elevated context.

Under these assumptions, I can think of just two solutions:

  • The list does not contain folders in the first place: I expect this is the first thing you would have checked, but it is worth mentioning anyway. Maybe the list is empty or whoever configured the "siturl" parameter made it point to the wrong list?
  • Your elevated context lacks permissions to actually read the available discussion/folder items.

You may ask how an elevated context may lack permission to do something. Remember: when you use SPSecurity.RunWithElevatedPrivileges your code will basically run under the Application Pool identity. The call is not performing any "permission elevation" magic other than that - so anything the Application Pool can't do, you will not be able to do even after the elevation.
Your first line:

string siteUrl = ConfigurationManager.AppSettings["siturl"];

shows that you are reading the url of the site that hosts the list from a configuration parameter. I would check two things:

  1. is the target site running under the same Application Pool account the service is running on? It is not uncommon for development environments to just use one account for everything, but this is not usually the case for production ones
  2. even if the Application Pool identity is the same, is this identity actually able to perform the read (this should be the case, but sometime miss-configuration can happen and cause situation where a web application App. Pool identity isn't able to actually read all data).

Based on the details you provided, I think you may be in case 1) - your services tries to access data found in a site that runs under a different, unrelated application pool identity and so elevation is failing. If that is the case, maybe you can try to re-impersonate the actual SystemAccount identity from the site the list is found on.

SPUserToken sysAccountToken = null;
SPSecurity.RunWithElevatedPrivileges(delegate()
{
    using (SPSite rwepSPSite = new SPSite(siteUrl))
    {
        sysAccountToken  = rwepSPSite.SystemAccount.UserToken;
    }
}

using (SPSite saSPSite = new SPSite(siteUrl, sysAccountToken))
using (SPWeb saSPWeb = saSPSite.OpenWeb())
{
    // your code here.
}

The above code should get the SystemAccount.UserToken and then use the token to perform elevation. If even this approach fails but you still believe that the problem is permission related, another possible approach would be storing some credentials in SharePoint Secure Storage... but this would be a lot more difficult and require more work so I would try this simpler approach first.

I hope this info may be useful. Sadly, as now, your question is pretty open-ended. Free to ask for more help if you find out any new useful detail about the issue and I will try to answer as I can.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.