.NET update on Azure breaking SharePoint provider hosted app parts (add-ins)

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.

This post is a contribution from Westley Hall, an engineer with the SharePoint Developer Support team

If you have a SharePoint provider hosted add-in running on Azure web services, and it stops working when hosted on a SharePoint page inside a app part (or client web part/add-in), or an iframe, then likely you have hit this issue caused by a change in the default cookie property SameSite.

After the last .NET update rollout, the SameSite property value on the ASP.NET_SessionId cookie is set to Lax which prevents the cookie from being sent to an iframe if the domain of the iframe is different than the host page. In a SharePoint provider hosted web part add-in, it will always be in a different domain.

Here is an example of that session cookie-

Set-Cookie: ASP.NET_SessionId=xxxxxxxx; path=/; HttpOnly; SameSite=Lax

Normally the xxxxxxx would be a random identifier of the session.

This session usually is used in the ASP.NET application to maintain the authentication, so what ends up happening is that the frame tries to redirect back to authenticate on the second time there is a post or any ajax call to the same app instead of using the session.

Sometimes it will throw a 405 Method Not Allowed error since ajax calls can trigger a CORS OPTIONS request, and that will be rejected by SharePoint.

To resolve this, set the defaults in the web.config as follows in the system.web section-

<system.web>
    <httpCookies sameSite="None" requireSSL="true"/>
    <sessionState cookieSameSite="None" />

When SameSite is set to None it doesn't force the requirement for the iframe and host to be in the same domain.

More on the .NET update here-

https://azure.microsoft.com/en-us/updates/app-service-samesite-cookie-update/

Here is how to update the Web.config file on the live instance of your Azure web app-

1. Navigate to your web application settings in Azure portal.
2. Click on Advanced Tools and click Go (in the red box).

3. In the Kudu screen click Debug console > CMD (in the red box).

This will bring you to the file view below-

4. Type the CD site\wwwroot command (lower red box) to get the root directory of the web application, and press Enter. The file list on the upper part of the page should refresh to show the Web.config file (you may need to scroll to see it). Click the edit icon (the pencil in a red box) to edit the file.

5. Add the httpCookies and sessionState cookie settings selected below. If the system.web section is missing, add it so that it looks like the sample below.

6. Click Save.
7. Confirm that your add-in web parts are working as expected.

This change should also be added to any source code projects that the web application was deployed from, for future deployments.