What is the difference between SPContext.Current.Web and SPContext.Current.Site.OpenWeb()?

Question

My colleague found that some scenarios of working with SPWeb objects depend on how you obtain them. I'm not talking of impersonating with UserTokens - that another story. But at times when you write web parts, you get some extra security constraints with SPContext.Current.Web that you don't suffer from with SPContext.Current.Site.OpenWeb().

Does anyone have any further technical guidance on the topic?

Answer 1

EDIT

Just like to clear this answer!

I've read your question and the answer has to do with the security context that has been put in place for a reason.

When using the SPContext.Current.Web or any context appart from .OpenWeb() it is already using the current users security context(read, write,full permissions). Open web is creating a new SPWeb object as I've already stated!

Because it's running under the current user's security context, say I have an account that has read only access its regardless weather I've done runwithelevated priv it wouldn't work because the security is already set, unless as you noted you use usertoken! That being said the code is trying to update or add an item to a list or library but fails as the security context under the current user wouldn't allow to give me the permission to run under pool account or even admin account.

Having the open web is run under a new thread that needs to be disposed of as I've noted first time round as its creating a new object, anything with the "new" object needs to be disposed and can be elevated so doesn't have any security restrictions (security). this can also be interchangeable between SPWebs/SPSites respectively.

This is not the case with SPContext.Current.Web , the only exception is when using the SPUser object where it would run into a known bug and running with elevated priv would do nothing, you would need to create a new SPUser and add SPWeb.EnsureUser(user.LoginName); within the elevated security context for it to work.

So rule of thumb SPContext.Current(like SPContext.Current.Web) uses the current user's security context tied to it making a tighter security around your code.

But SPContext.Current.Site.OpenWeb() creates a new SPWeb object that doesn't have any security context tied to it, leaving you to change security context or elevate privs without restrictions!

Both open the same SPWeb or SPSite, the only difference is the security context tied to the current context of the user that you should not dispose of!

.........................

Just as a note:

There are a few key takeaways for SharePoint projects:

• Always dispose your SPWeb / SPSite objects --> memory leaks
• Make use of SPContext.Current... when you are sure your code is running in a SharePoint context
• Unit Tests mean no Sharepoint context
• External utilities mean no Sharepoint context
• Powershell means no SharePoint context (e.g. activating a feature with feature receiver might fail)
•Do not dispose SPContext.Current... but create your own object (again using) You might have problems with consistency with your multiple SP.. objects.

In the end SPSite site = SPContext.Current.Web.Site; is fine in some instances, but you do not have control over this site object - that might be the problem. If you go for new SPSite(...) you will always have your SPSite and not something SharePoint created and managed for you.

Personally I almost always go for the using structure so all objects are disposed properly afterwards. When I do quick and dirty solutions I use SPContext.Current.Web without disposing.

https://stackoverflow.com/questions/8052190/spsite-site-new-spsitespcontext-current-web-url-vs-spcontext-current-web-sit

Also as I've said:

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 [meaning 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 created within theRunWithElevatedPrivileges code block as above.

in this case SPContext.Current.Site.OpenWeb() creates a new thread from the current context and is like creating a new spweb, this means more control but also means you need to dispose of the object.

http://sharepointquicksolutions.blogspot.in/2012/11/all-ways-of-runwithelevatedprivileges.html

So you can see the picture here! That there are less privileges to the CurrentContext that's using the same thread eg SPContext.Current.Web whereas SPContext.Current.Site.OpenWeb() is a new thread that doesn't have the restrictions in place due to the first one already being set and used whereas the second one is created by you and can be changed (security wise) means no restrictions on actions but also means you need to handle the disposing of the SPWeb object.

Answer 2

I see two differences one difference:

1. The function SPContext.Current.Site.OpenWeb() creates a new instance of the SPWeb object, and you are responsible to dispose it.
   However, SPContext.Current.Web gives you access to the current instance of SPWeb, and you must not dispose it.
2. The function SPContext.Current.Site.OpenWeb() (without sending parameters) opens the root web of the current site collection,
   And SPContext.Current.Web gives the current subsite.
   If you are in any subsite that is not the root web - you will get a different web in each approach.

Edit:
I always knew that SPSite.OpenWeb() opens the root web, I did not think even for a moment that SPContext.Current.Site.OpenWeb() will do something else.
But now I debug it, and to my astonishment I discovered that it opens the current web and not the root web!

To understand how this happens I opened the code in Reflector and I saw that the function SPSite.OpenWeb() is defined there like this:

public SPWeb OpenWeb()
{
    return new SPWeb(this, this.DefaultPageUrl, false);
}

And oddly enough, when using SPContext.Current.Site - the property DefaultPageUrl contains the URL of the current page, so the function OpenWeb() opens the current web.
So what I wrote earlier was not true. There is only one difference between the two approaches.

Answer 3

For one, if you create a new instance of SPWeb using SPContext.Current.Site.OpenWeb() you now own that instance and need to dispose of it yourself.

Answer 4

You could re-write these definitions like this

$context = SPContext.Current.Web

and like this

$context = SPContext.Current.Site
$myweb = $context.Web(guid/url)

My understanding is these are two different contexts: one is the Web's context, the other is the Site Collection's context (which is then referencing one of its webs).

SPContext.Current This provides context for the current http request

SPContext.Current.Web works in the context of your current Web

SPContext.Current.Site.OpenWeb(guid/url) works in the context of your current Site Collection*, and you are opening a Web within that Site Collection. This context gives you the added scope to target other Webs too.

A dorky analogy would be Hotel Site Collection and the rooms are your Webs. You have a guest and a hotel manager. The guest's context is the room he's in, the manager's context is the whole hotel. The guest can only act on the room he is in. The manager can act on any room in the hotel, even while standing in the guest's room.

*Site Collection context should not be confused with Web context for the top-level Web of your site topology - that would still just be a Web context.

You can act on the lobby, gateway to all hotel rooms, but that doesn't make you a hotel manager.

As Current.Web you can only operate inside that Web. As Current.Site you have a broader scope, and can operate in the site collection and in multiple Webs under that Site Collection.

You may also benefit from these great answers on using web objects:

Using SPContext.Current or using static URL

Why we shouldn't use SPWeb witryna = SPContext.Current.Web;

Answer 5

I will go with this point as a developer and business solution :

SPContext.Current.Site.OpenWeb() opens the root web of the current site collection, SPContext.Current.Web gives the current subsite.