2

I have a working SharePoint provider hosted app, with an MVC web application residing on an Azure Web site. Entering the full screen app page, everything looks as expected.

Adding a client web part or manually adding an iframe via a Script Editor web part, pointing at the exact same web application, results in no context token returned from the TokenHelper.

I have the following method in an MVC controller:

public ActionResult Index()
{
    var contextToken = TokenHelper.GetContextTokenFromRequest(Request);

    // store the context token to use subsequently    

    return View();
}

Further investigation reveals that the TokenHelper.GetContextTokenFromRequest returns null as the request form does not contain the "SPAppToken", when called from the iframe.

Can someone shed some light on the difference between the fullscreen app and the app hosted in an iframe/client web part?

Improve this question

2 Answers 2

Reset to default
0

You should probably just use the new SharePointContext helper that was added in VS2013. It abstracts out many of the TokenHelper nuances that were somewhat annoying to deal with -- getting a token if one isn't present, using refresh tokens to get access tokens, saving the token across multiple pages in your app... etc.

That's just advice in general, but specific to your question the SharePointContext helper will understand how to go get a new token if your ClientWebPart wasn't given one as part of the initial request.

In your ASP.NET project, you should see a SharePointContext.cs file that has the code for the context helper.

Here is a brief example of using the context helper instead of the token helper from a good SP Blog article on MSDN: http://blogs.msdn.com/b/officeapps/archive/2013/11/07/announcing-the-new-sharepointcontext-helper-in-apps-for-sharepoint-2013.aspx

var spContext = 
    SharePointContextProvider.Current.GetSharePointContext(HttpContext);

using (var clientContext = spContext.CreateUserClientContextForSPHost())
{
    if (clientContext != null)
    {
        User spUser = clientContext.Web.CurrentUser;
        clientContext.Load(spUser, user => user.Title);
        clientContext.ExecuteQuery();
    }
}

Something else that applies either way (TokenHelper or Context Helper) -- you should make sure you're passing the {StandardTokens} tokens to all of your pages -- you have to set this for your ClientWebPart seperately in the App manifest.The context helper depends on the URLs provided in the {StandardTokens} to figure out how to create the right access tokens.

Improve this answer
4
  • The SharePoint app was originally an autohosted app, which has been ported to a provider hosted app. SharePointContext has been altered considerably since then; it would be a rather cumbersome task to rewrite the original app. Is there no way to obtain the SPAppToken in the "new" SharePointContext helper? And why is it different, when accessing the Azure website from within an iFrame - shouldn't that be "taken care of"?
    – Lasse B.
    Dec 11, 2014 at 14:05
  • Try passing {StandardTokens} to your ClientWebPart first and see if that solves things... that is a manual step that you have to do where VS doesn't really help you out or give you a hint on
    – John-M
    Dec 11, 2014 at 14:46
  • I already do pass {StandardTokens} in ClientWebPart and I can verify these values in Fiddler ;-). The strange thing is that it appears to work now, if I enter the fullscreen app first, and then enter the host web page, where the ClientWebPart is located - but not the other way around. Seems like a cookie issue of sorts - I've tested it in IE, FF and Chrome.
    – Lasse B.
    Dec 12, 2014 at 8:17
  • That makes sense because of cookies as you suggest; if it works on full screen mode you'll still have a valid cookie when you view it via the app part. The only thing I can think of is that the page your ClientWebPart directs to is different or recieving different parameters than your full page is. I would still just refactor all the authentication logic to use the SharePointContextProvider, but that's just because it's really simple to use :) Otherwise track down why the clientwebpart is different than the full screeen experience
    – John-M
    Dec 12, 2014 at 13:45
0

Refactoring the app to use the "new and improved" SharePointContext was not possible within the given timeframe. After recreating the client web part and registering the app anew, it seems to work now. I did not find the reason for the missing access token, though, but using the old TokenHelper class to retrieve the token and letting the client web part do its job works (for now).

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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