4

Im not sure if this is possible without impersonating a user/service account (and therefore hard coding credentials) that has farm level access...

The situation is I want to access an SPSite in another web application (not the context web app my code is runnning in). The context web application and the web application I want to access have different application pool identities so SPSecurity.RunWithElevatedPrivileges fails (as it should). Is there a method that anyone can suggest to gain access to resources in another web application?

Improve this question
2

if you open the target SPSite, without RunWithElevatedPrivileges, you should be able to get the SPUserToken for the SystemAccount of that SPSite via SPSite.SystemAccount.UserToken (I just hope you have access to this!)

Using that usertoken, you should be able to re-open that same SPSite, this time passing in that usertoken in the constructor.

At this point you should have an SPSite object, which you can use as if you had opened it with RunWithElevatedPrivileges. You can google search for the differences between RunWithElevatedPrivileges and opening SPSites with SPUserTokens.

Improve this answer
3
  • 1
    In general using SPUserToken should be recommended over using RWEP, especially for non-read operations. The problem with the above is, as you mention, that you need access to get that token or you will get an AccessDenied- or UnauthorizedAccessException (cant remember which). To avoid that... you need RWEP that wont work since they are running on different app pools with different identities. – Anders Rask Mar 5 '10 at 12:47
  • Agree w/Anders. Impersonating the system account (which is the approach here) will not work in this scenario. – Paul Schaeflein Mar 5 '10 at 14:41
  • Thanks Jaap - I think the the token approach is definately more elegant than RWEP. Unfortunately both the user and the application pool dont have rights to get to the target SPSite which is why Im trying to find a way to elevate the rights further. – Nick Hadlee Mar 6 '10 at 7:02
0

If you are reading, perhaps Search can help. Or web services or RSS, but that would be bad in a web request context.

I don't know your requirements, but do you really need to do this? If so, do you need to do it in real time from a web page?

Improve this answer
3
  • 1
    Paul, what is bad about using web services in this scenario? That is where my thoughts went straight away. Just curious, because in essence it would be the same as accessing a 3rd party web service from a web context which seems appropriate to me. – Charles Lee Mar 5 '10 at 9:25
  • Making a web request on the server in real-time will kill performance. If the page is accessed frequently, I would retrieve the information out-of-band (jQuery from the browser) or use a background process to retrieve and cache it. – Paul Schaeflein Mar 5 '10 at 14:39
  • Paul/Charles - thanks for the responses. This is to implement a work around because an issue with the search svc was introduced post SP2 making it useless for my current requirements (its being investigated via a MS support call). Normally Id prefer using search for performance/load reasons. The calls are being made asynchronously and caching is also implemented to try & alleviate any possible performance issues. Keith Dahlby suggested implementing a service on the target web apps that returns the necessary info and I’m starting to think this is the most viable option. – Nick Hadlee Mar 6 '10 at 6:58
0
        SPSite siteAux = new SPSite(url);
        SPUserToken spUserToken = siteAux.SystemAccount.UserToken;
        siteAux.Close();
        _site = new SPSite(url, spUserToken);
        _site.AllowUnsafeUpdates = true;
        _web = _site.OpenWeb();
        _web.AllowUnsafeUpdates = true;
        _sPList = _web.Lists[listName];
Improve this answer

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.