SharePoint Interview Questions?

What is the Master Page and Use of it?

Master page provides layouts for set of pages. Master Pages are a template that other pages can inherit from to keep consistent functionality. The pages that inherit from Master Pages are referred to as content pages.

In SharePoint, when we add a new page from browser by going to Site Actions and select Create Page then there we will select the page layout and create the page. So we are selecting the page layout, it’s always binds to a master page. Whenever you change the default or custom master page, then the changes will be applied to all the page layouts by default. Because SharePoint won’t give direct master page URL or name anywhere. It will be ~masterurl/custom.master for custom master page and ~masterurl/default.master for the default master page.

Types of Master Pages in SharePoint?

There are 3 types of Master Pages in SharePoint

System Master Pages-are used for Non-Publishing Site and Subpages(list or libraries) in Publishing Site

Site Master Pages-are usually used in Publishing Site Main Page or sub sites
Application Master Pages are all Layout Pages.Layout pages are SharePoint administrartive pages

Difference between SPList TryGetList and Web.List

 1.SPList list=web.List.TryGetList("listName")
 Here "listName" is the name of the list and returns a SPList object.But if list is not available it will not through any exception.It will return null value.
2.SPList list=web.list["listName"]
But here if the list does not exists then it will throw an exception.

All ways of RunWithElevatedPrivileges

Download it:
https://sites.google.com/site/sasivalipireddy/home/RunWithElevatedPrivileages_ALL.pdf 

1. RunWithElevatedPrivileges?
2. Why can’t we use RunWithElevatedPrivileges in event handlers?
3. Impersonation Improvements in SharePoint 2010 Event Receivers?
4. Best recommended practice use of it?
5. Best recommended practice to use of it in Event Receivers?
6. Best recommended practice to use of it in Feature Receivers?
7. RunWithElevatedPrivileges in visual studio workflows:
8. Is RunWithElevatedPrivileges allowed in sandbox solution?
9. By using which credentials the RunWithElevatedPrivileges will run?
10. Difference between SPSecurity.CodeToRunElevated and SPSecurity. RunWithElevatedPrivileges?

Impersonation:

Impersonation is the process of executing code in the context (or on behalf) of another user identity.

What are the Impersonation methods in SharePoint 2010?

• RunWithElevatedPrivileges to impersonate as System Account user
• Passing User Token inside SPSite to impersonate as particular user
• Using Windows API

SPUserToken:

The SPSite object takes an SPUserToken object in its constructor in order to support impersonation.To impersonate the system, use the SystemAccount.UserToken property of the current SPSite context, such as:
var site = new SPSite(SPContext.Current.Site.ID, SPContext.Current.Site.SystemAccount.UserToken);

Difference between RunWithElevatedPrivileges Vs SPUserToken:

• RunWithElevatedPrivileges to impersonate as System Account user
• Passing User Token inside SPSite to impersonate as particular user

RunWithElevatedPrivileges?

As per the msdn: Executes the specified method with Full Control rights even if the user does not otherwise have Full Control. 

Whenever we use SPSecurity.RunWithElevatedPrivileges (), it will execute the code under the context of Application Pool identity, so you must ensure that the App Pool account is a member of a site collection group with sufficient perms to add/edit/delete or whatever your code is trying to do. If not, the code will quietly break without popping an exception.

Method: Microsoft.SharePoint. SPSecurity.RunWithElevatedPrivileges

The code will not run within the elevated privilege if the object accessed was not created within the SPSecurity.RunWithElevatedPrivileges block. The main reason for doing so is to ensure that all the objects are in the context of the App Pool's identity.


SPSecurity.RunWithElevatedPrieveleges, there are too much tricks that you should take care of.
For Instance: You must create the new SPSite objects inside the delegate because SPSite objects created outside do not have Full Control even when referenced inside the delegate.

RunWithElevatedPrivileges does not work when HTTPContext is null:
RunWithElevatedPrivileges don’t work when HTTPContext (SPContext to be more specific) is null. So, you will not have elevation of privilege when using RunWithElevatedPrivileges in Console Application, Workflow, Timer Job or Event handlers not initiated by a request in browser.

What is the need of defining SPSite, SPWeb objects especially in RunWithElevatedPrivileges block? 
If you use instances of SPSite or SPWeb, obtained prior to the RunWithElevatedPrivileges block, it won't work as expected because they are already associated to a non-elevated security context[ means current logger user] 

Why can’t we use SPContext.Current.Web inside RunWithElevatedPrivileges:

SPContext.Current.Web can not be used directly with in the RunWithElevatedPrivileges block as the SPWeb object becomes a instance of current logged-in user's context and it gives the below error if tries to update any content in the same Web with READ only access.
Error : Unable to evaluate expression because the code is optimized or a native frame is on top of the call stack.
To address the issue, a new instance of SPSite and SPWeb should be cerated within the RunWithElevatedPrivileges code block as above. 

Impersonation Improvements in SharePoint 2010 Event Receivers?

Instead of using RunWithElevatedPrivileges, In SharePoint 2010, there are new properties namely OriginatingUserToken, UserDisplayName and UserLoginName which help the developers to revert back to the original user who triggered the event very easily. 

I will update once get the clear idea on what use of the new properties OriginatingUserToken, UserDisplayName and UserLoginName introduced in SharePoint 2010.

RunWithElevatedPrivileges in visual studio workflows:

No need to use any elevated privileges when working with workflows because it runs under SharePoint System Account by default (the App Pool account).

Is RunWithElevatedPrivileges allowed in sandbox solution?

You cannot use SPSecurity.RunWithElevatedPrivileges method in case of Sandboxed solution. The main reason is Sandbox solutions execute in User Code service with limited privileges.

Best recommended practice use of it:

Can’t use SPContext inside the code being RunWithElevatedPrivileges. We may get “access denied” error if instead write the SPWeb site = SPContext.Current.Web inside the RunWithElevatedPrivileges, because your web was created in the context of the current user.

Best recommended practice is: Take the current context outside the SPSecurity.RunWithElevatedPrivileges block and then create a new instance of SPSite and SPWeb inside the block which will run under application pool identity.

Simply to say is: The objects you’re working with need to be recreated within your RunWithElevatedPrivileges code block.

Recommended practice #1:

view plainprint?

1. private void Test()  
2. {  
3.     Guid webID = SPContext.Current.Web.ID;  
4.     Guid siteID = SPContext.Current.Site.ID;  
5.     SPSecurity.RunWithElevatedPrivileges(delegate()  
6.     {  
7.         using (SPSite site = new SPSite(siteID))  
8.         {  
9.             using (SPWeb web = site.OpenWeb(webID))  
10.             {  
11.                 // Code Using the SPWeb Object goes here  
12.             }  
13.         }  
14.     });  
15. }  

Best recommended practice #2:

view plainprint?

1. private void Test()  
2.         {  
3.             SPSite site = SPContext.Current.Site;  
4.             SPWeb web = SPContext.Current.Web;  
5.   
6.             SPSecurity.RunWithElevatedPrivileges(delegate()  
7.             {  
8.                 using (SPSite CurrentSite = new SPSite(site.ID))  
9.                 {  
10.                     using (SPWeb CurrentWeb = CurrentSite.OpenWeb(web.ID))  
11.                     {  
12.                         // Code Using the SPWeb Object goes here  
13.                     }  
14.                 }  
15.             });  
16.         }  

RunWithElevatedPrivileges” in Feature Receivers:

view plainprint?

1. [Guid("b321499d-9b43-410e-8a8f-779ffb81d738")]  
2.     public class Feature1EventReceiver : SPFeatureReceiver  
3.     {  
4.         public override void FeatureActivated(SPFeatureReceiverProperties properties)  
5.         {  
6.             try  
7.             {  
8.                 using (SPSite spSite = properties.Feature.Parent as SPSite)  
9.                 {  
10.                     using (SPWeb spWeb = spSite.OpenWeb())  
11.                     {  
12.                         SPSecurity.RunWithElevatedPrivileges(delegate()  
13.                         {  
14.                             //code here  
15.                         });  
16.                     }  
17.                 }  
18.             }  
19.             catch (Exception ex)  
20.             {  
21.             }  
22.         }  

“RunWithElevatedPrivileges” in Event Receivers: Better to use the ID properties of the properties object, to get new instances of SPSite, SPWeb and SPListItem. If you need to run actions with elevated privileges on SPSite and SPWeb object use new SPSite(properties.SiteId); and site.OpenWeb(properties.RelativeWebUrl) instead of properties.web and web.site;

Best Recommended Practice #1

view plainprint?

1. namespace MyCustomDlgFramework.EventReceiver  
2. {  
3.     /// <summary>  
4.     /// List Item Events  
5.     /// </summary>  
6.     public class EventReceiver : SPItemEventReceiver  
7.     {  
8.        /// <summary>  
9.        /// An item is being added.  
10.        /// </summary>  
11.        public override void ItemAdding(SPItemEventProperties properties)  
12.        {  
13.            SPSecurity.RunWithElevatedPrivileges(delegate()  
14.            {  
15.                using (SPSite site = new SPSite(properties.SiteId))  
16.                {  
17.                    using (SPWeb web = site.OpenWeb(properties.RelativeWebUrl))  
18.                    {  
19.                        //code here  
20.                    }  
21.                }  
22.            });  
23.              
24.        }  
25.   
26.     }  
27. }  

Best recommended practice #2:

view plainprint?

1. namespace MyCustomDlgFramework.MyEventReceiver  
2. {  
3.     /// <summary>  
4.     /// List Item Events  
5.     /// </summary>  
6.     public class MyEventReceiver : SPItemEventReceiver  
7.     {  
8.        /// <summary>  
9.        /// An item is being added.  
10.        /// </summary>  
11.        public override void ItemAdding(SPItemEventProperties properties)  
12.        {  
13.             using (SPSite site = new SPSite(properties.WebUrl))  
14.            {  
15.                using (SPWeb web = site.OpenWeb())  
16.                {  
17.                    SPSecurity.RunWithElevatedPrivileges(delegate()  
18.                    {    
19.                        //Code here  
20.                    });  
21.                }  
22.         }  
23.     }  
24.   }  
25. }  

Best recommended practice #3:

view plainprint?

1. namespace MyCustomDlgFramework.EventReceiver  
2. {  
3.     /// <summary>  
4.     /// List Item Events  
5.     /// </summary>  
6.     public class EventReceiver : SPItemEventReceiver  
7.     {  
8.        /// <summary>  
9.        /// An item is being added.  
10.        /// </summary>  
11.        public override void ItemAdding(SPItemEventProperties properties)  
12.        {  
13.            SPSecurity.RunWithElevatedPrivileges(delegate()  
14.            {  
15.                using (SPWeb web = properties.OpenWeb())  
16.                {  
17.                    //Code here  
18.                }  
19.   
20.            });  
21.        }  
22.   
23.     }  
24. }  

Chances of getting “Access Dined” error:

Note: Elevation of privilege occurs only if new SPSite created inside the block : 

view plainprint?

1. private void Test()  
2.         {  
3.             SPSecurity.RunWithElevatedPrivileges(delegate()  
4.             {  
5.                 SPWeb currentWeb = SPContext.Current.Web;  
6.                 SPList spList = currentWeb.Lists["MyList"];  
7.             });  
8.         }  

view plainprint?

1. private void Test()  
2. {  
3.     SPSecurity.RunWithElevatedPrivileges(delegate()  
4.     {  
5.         using (SPSite currentSite = new SPSite(SPContext.Current.Site.Url))  
6.         {  
7.             using (SPWeb currentWeb = currentSite.OpenWeb())  
8.             {  
9.                 // Access granted as System account!!   
10.             }  
11.         }  
12.     });  
13. }  

view plainprint?

1. private void Test()  
2.         {  
3.             SPSecurity.RunWithElevatedPrivileges(delegate()  
4.             {  
5.                 SPSite site = SPContext.Current.Site;  
6.                 SPWeb web = SPContext.Current.Web;  
7.                 web.AllowUnsafeUpdates = true;  
8.   
9.                 SPList list = web.Lists["MyList"];  
10.                 SPListItem item = list.GetItemById(1);  
11.                 item["MyField"] = "SharePoint";  
12.                 item.Update();  
13.   
14.                 web.AllowUnsafeUpdates = false;  
15.             });  
16.         }  

When/where/why use "AllowUnsafeUpdates" in SharePoint?

As per msdn article “AllowUnsafeUpdates is set to true when you are trying to update the database as a result of the GET request”. 

E.g. Say you have a list and you want to update something to the SharePoint data [content DB], then you need to set AllowUnsafeUpdates = true for the web and after you have done you need to set it back to false. 

What will happen if you set as AllowUnsafeUpdates to false? And what is preventing it from cross site scripting attacks?  Yes, the FormDigest control is taking care of all about it. I have already explained about “FormDigest’ control in previous post. Please go through to get more on it here. 

To GET the content from the content DB, we need to set the AllowUnsafeUpdates = true. 

To POST the content to the content DB, not require to set the AllowUnsafeUpdates = true. why means because of "FormDigest" control placed in every master page.

For reasons of security, by default, Microsoft SharePoint Foundation does not allow you to make posts from a Web application to modify the contents of the database unless you include security validation on the page making the request.  You can update data for a single site or for a site collection by adding a page directive and a FormDigest control to the page that makes the request.

How to do manipulation to the SharePoint data programmatically?

So if you need to allow your code to make some updates, you need to set allow unsafe updates to true and then back to false as soon you update.

SPList list= web.Lists["list name"];
SPListItemCollection items= list.GetItems();
web.AllowUnsafeUpdates = true;
foreach (SPListItem item in items)
{
     item["Field"] = "new val";
     item.Update();
}
web.AllowUnsafeUpdates = false;

Remembering point on "AllowUnsafeUpdates"

• You can set it true to true to avoid security validation before the changes are written to the content database.
• GET Request needs  "AllowUnsafeUpdates" enabled before updating the sharepoint objects.
•  POST request doesn't need "AllowUnsafeUpdates" before updating in sharepoint objects.
• updates are currently disallowed on GET requests. To allow updates on GET, set the"AllowUnsafeUpdates" property to true.
• Always set AllowUnsafeUpdates back to true after you break inheritance in an environment with HTTPContext.
• What I have learned the hard way today is that when you set the AllowUnsafeUpdates property to true and your code jumps to the catch block of a try/catch statement that property will be set to false again.
• Remember if you inherit the page from WebPartPage class then no need to use AllowUnsafeUpdates.
  

Please refer to know more on “AllowUnsafeUpdates” with some real-time examples here:

• How to create/update/delete a list in SharePoint pro-grammatically

Static Web part Vs. Dynamic Web part

Static Web part Vs. Dynamic Web part: A Web Part zone typically contains one or two Web Parts. However, Web Parts do not have to be placed into a zone on the Web Part Page.
Static Web part	Dynamic Web part
Web Parts that are placed outside of a Web Part zone are called static Web Parts.	Web Parts that are contained within a Web Part zone are called dynamic Web Parts.
They are treated and act just like a standard Web control.	They are treated and act just like a standard Web part.
A static Web Part and its properties are stored within the Web Part Page (.aspx) file.	The properties of a dynamic Web Part are saved to a content database.
A user cannot interact with a static Web Part or modify it within a browser.	Users can access the properties and manipulate these properties.