.NET update on Azure breaking SharePoint provider hosted app parts (add-ins)
Published Jan 27 2020 02:35 PM 7,071 Views
Microsoft

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).
 

clipboard_image_10.png

 

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

clipboard_image_9.png

This will bring you to the file view below-

 

clipboard_image_8.png

 

 

  1. 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.

 

 

clipboard_image_12.png

 

  1. 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.

 

clipboard_image_5.png

 
  1. Click Save.
  2. 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.

10 Comments
Copper Contributor

This didn't work for me; it just resulted in an error.  However, I managed to achieve the same thing by using a rewrite rule:

 

    <rewrite>
      <outboundRules>
        <rule name="Add SameSite" preCondition="No SameSite">
          <match serverVariable="RESPONSE_Set_Cookie" pattern=".*" negate="false" />
          <action type="Rewrite" value="{R:0}; SameSite=none" />
          <conditions>
          </conditions>
        </rule>
        <preConditions>
          <preCondition name="No SameSite">
            <add input="{RESPONSE_Set_Cookie}" pattern="." />
            <add input="{RESPONSE_Set_Cookie}" pattern="; SameSite=none" negate="true" />
          </preCondition>
        </preConditions>
      </outboundRules>
    </rewrite>

 

This goes in system.webServer in web.config.

Microsoft

URL re-write is a heavier way of doing the same thing the web.config setting does. 

If you give the error, we might be able to get it working with the more efficient solution.

Make sure you have well formed XML, that will throw errors if it is off.

Copper Contributor

Well, the intellisense hadn't recognised the attributes when adding them in Visual Studio, so when I deployed, tested, and got an error, I just thought the xml couldn't being parsed, and that perhaps these attributes were only valid on framework 4.7 onwards (I'm targeting 4.6.1).  However, I played around with it a bit more yesterday and ended up putting just the sessionState line back in - and that was OK.  So I decided to check that it must just be the httpCookies line, added that back in, and...it still worked.  So I think perhaps what happened was that in copying and pasting the two lines together from this page, there were maybe some hidden characters introduced which resulted in malformed xml.  That's all I can think of, anyway. Thanks for responding, though, and hope this helps someone else.

Copper Contributor

I am using NET 4.7.2 and tried the fix in web.config file and got warning "The 'sameSite' attribute is not allowed.". Should I ignore this?

 

Temp2.png

Copper Contributor

I think you might just need to validate against another schema (which is what I ended up doing).  With the web config open, go to the XML menu at the top and choose Schemas. There should be one in the list called DotNetConfig472.xsd.  Make sure the "Use" column is set to "Use this schema". 

 

You also have the targetFramework for httpRuntime set to 4.5 instead of 4.7.2.

Copper Contributor

I Can not find "DotNetConfig472.xsd". The only schema that I can see is "DotNetConfig.xsd"

 

Temp2.png

Copper Contributor

Oh well, try ignoring the error and deploying anyway.  You could even edit the web config directly in Azure as suggested in this article.

Copper Contributor

I tried with VS2019 and it has the valid schema file but error is still there

 

Temp2.png

Copper Contributor

Thanks @stmaximon 

 

Microsoft

Note that the system.web configuration settings have no effect in .NET Core, and applications written on .NET Core will require a code change to the configuration to use CookieOptions.SameSite == SameSiteMode.None in a cookie policy, or when setting the cookie authentication up. There is a bit here on using OWIN to code a solution that also will omit the SameSite property when dealing with certain browser agents that are not up to date on the standard yet (and may never be updated)-

https://devblogs.microsoft.com/aspnet/upcoming-samesite-cookie-changes-in-asp-net-and-asp-net-core/

 

The URL re-write workaround I believe was nessecitated by the use of .NET Core on some apps, while apps that were built on .NET Framework worked with the cookie settings in the system.web config section.

Version history
Last update:
‎Aug 27 2020 03:39 PM
Updated by: