Known Issue: Behavioral change in browsers for  handling Cookies causes too many redirects error

Issue

If you are using Chrome Update 80 or later or Microsoft Edge 80.0.361.48 or later, you may experience an issue where an infinite loop occurs when authenticating with a K2 web page hosted in an iframe when the K2 web page hosted in the iframe is located in another domain. This could typically result in errors such as :

  • redirected you too many times
  • ERR_TOO_MANY_REDIRECTS
  • An error occurred while processing a WS-Federation sign-in response

This is a result of the web browser's behavior for handling browser cookies with the SameSite property.

The issue could affect K2 Five, K2 Cloud, K2 4.7 and K2 blackpearl environments, depending on how you interact with K2 sites and SmartForms.  

Old versions of Chrome and other browsers do not support the SameSite cookie attribute, which could also result in similar errors; for this reason, it is recommended that browser versions should be as close to the current version of a browser as possible.

If your K2 sites are configured for HTTP and not HTTPS, you may see similar errors.  This is because Chrome will only send a cookie for a site in an iframe if both SameSite=None and Secure are configured as cookie attributes. When a cookie has the Secure attribute set, the cookie will not be sent over HTTP - only HTTPS is permitted. 

Symptoms

For example: if a K2 Site (such as the SmartForms runtime site) is located on one domain (for example k2.externaldomain.com), and you are trying to access the SmartForms page from another domain (for example portal.internaldomain.com) through an iframe, the K2 site might not load correctly, and could enter an infinite loop when authenticating against the K2 site. 

Here is an example where the K2 SmartForms Viewer webpart is used to display a K2 form located at k2.external.com from a SharePoint site located at portal.denallix.com, and using Chrome 80. Because the webpart iframe is trying to access a URL located on a different domain, the infinite loop occurs and the redirect error is shown:

You may see an error screen similar to the example below if you use SharePoint Online: 

Cause

The issue occurs because of a behavioral change in Chrome 80 for handling cookies that do not explicitly set the SameSite cookie attribute to None. See the Google topic Cookies default to SameSite=Lax for more information on the changed behavior in Chrome 80.

This change is expected to cause issues in K2 for SharePoint components when activating a site, the K2 SmartForms Viewer webpart, SharePoint list and libraries that are integrated with K2, or any other sites that embed a K2 site through an iframe and where the site’s domain is different from the K2 site’s domain. It could also occur if a web browser does not support the SameSite cookie attribute. 

It is expected that other browsers are planning to incorporate the same behavior. Until such updates are available, please review the possible resolutions you can implement. 

Resolution

There are different ways in which you can resolve the issue.  

Recommended fix: Install latest .NET 4.7.2 and updates or 4.8 and updates, and edit web.config (K2 Five only)

With the latest updates to .NET 4.7.2 and 4.8 (https://docs.microsoft.com/en-us/aspnet/samesite/kbs-samesite), IIS administrators can configure the SameSite attribute for cookies in each affected site. This recommended fix is also the approach that K2 will use for upcoming versions of K2.

  • This resolution only applies to K2 Five, since K2 blackpearl does not fully support .NET 4.7.2/.NET 4.8
  • Your K2 sites must be configured to use HTTPS, since the requireSSL configuration value must be set to true if cookieSameSite is set to true
  1. If necessary, install .NET 4.7.2 or .NET 4.8 (The next version of K2 will require .NET 4.8, so you may want to take the opportunity to install .NET 4.8 at this point, but you can still use .NET 4.7.2 if you are not ready to install .NET 4.8) 
  2. Install the latest updates for .NET 4.7.2 or .NET 4.8, depending on the version of .NET you have installed 
  3. Make the following changes in the web.config file for K2 sites affected (e.g. the SmartForms Runtime site, K2 Designer site, and the Viewflow site)
    1. Under the <system.web> section, add the following: 
      <httpCookies requireSSL="true" sameSite="None"/>
    2. Search for requireSSL throughout the web.config file, and change the value from false to true
    3. Search for <forms and edit the entry by adding cookieSameSite="None"  as shown below: 
      <forms defaultUrl="Default.aspx" loginUrl="_trust/Login.aspx" requireSSL="true" enableCrossAppRedirects="true" cookieless="AutoDetect" timeout="9000" cookieSameSite="None" />
    4. Search for <sessionState and add cookieSameSite="None" to the element as shown below:
      <sessionState mode="Off" cookieSameSite="None" />
  4. If your environment uses FormsSTS, edit the web.config in [k2 installation directory]\ WebServices\Identity\Sts\Forms and make the following changes:
    1. Search for <forms and edit the entry to look like this:
      <forms loginUrl="~/Account/Login" defaultUrl="." timeout="2880" requireSSL="true" cookieSameSite="None"/>
    2. Under the <system.web> section add the following:
      <httpCookies requireSSL="true" sameSite="None"/>
  5. If your environment uses WindowsSTS, edit the web.config in [k2 installation directory]\ WebServices\Identity\Sts\Windows and make the following changes:
    1. Under the <system.web> section add the following:
      <httpCookies requireSSL="true" sameSite="None"/>
  6. Perform an IISRESET
  7. Users will need to log out of K2 and log back in for the change to properly take effect
  • This workaround will cause Safari to treat cookies as SameSite=Strict due to a bug in the Safari browser that has not yet been resolved. This will result in Safari encountering the same types of errors described in this article. 
  • This workaround will cause an error like Unrecognized attribute ‘cookieSameSite’ in IIS’s Authentication Configuration screen for the affected sites. This is an issue within IIS due to IIS that has not yet been aligned to cater for the cookieSameSite attribute on the forms authentication configuration section.  The same error will occur in K2’s installer when doing a reconfiguration or running the Configuration Analysis tool. You can safely ignore this error as it does not cause any functional problems. K2 will update the installer in future versions to handle this error. 

Alternative Workaround 1: Disable default behavior in Chrome (K2 Five, K2 Cloud, K2 4.7)

You can change the default behavior in Chrome by disabling the appropriate feature flags. To do this, enter the following values into the address bar in Chrome:

  • chrome://flags/#same-site-by-default-cookies
  • chrome://flags/#cookies-without-same-site-must-be-secure

This setting will change the default behavior for all sites, not just K2 sites. For more information, please see https://support.google.com/chrome/thread/26291731?hl=en

Alternative Workaround 2: Configure URL Rewrite rule to add SameSite=None to all cookies (K2 Five, K2 4.7)

IIS administrators can configure a URL Rewrite rule in IIS to automatically add the SameSite=None attribute to all K2 cookies to restore the behavior to pre-Chrome 80.

  1. This approach will only work if the K2 Site is running on HTTPS and only if cookies are configured with the Secure attribute.  If the sites are already using secure cookies, skip to Step 2. If your sites are not configured to use secure cookies, edit the web.config of the K2 sites affected by this change (e.g. the SmartForms Runtime site, K2 Designer site, and the Viewflow site) with the following two changes:
    1. Search for RequireSSL throughout the file, and change the value from false to true
    2. Search for <httpCookies 
      If no results are found, add the following under the <system.web> node:
      <httpCookies httpOnlyCookies="true" requireSSL= "true" />
  2. Ensure that the URL Rewrite module is installed in all IIS servers hosting K2 sites affected by this change. 
  3. Edit the  web.config file of the K2 sites affected by this change (e.g. the SmartForms Runtime site, K2 Designer site, and the Viewflow site) and add the following section to the <system.webserver> node in these web.config files (make a backup of the config files before you edit them) 

    <rewrite>
      <outboundRules>
        <rule name="Add SameSite" preCondition="No SameSite">
          <match serverVariable="RESPONSE_Set_Cookie" pattern=".*" negate="false" />
          <conditions logicalGrouping="MatchAny">
           <add input="{HTTP_USER_AGENT}" pattern=".*Chrome" />
          </conditions>
          <action type="Rewrite" value="{R:0}; SameSite=None" />
        </rule>
        <rule name="Replace SameSite Lax and Strict">
          <match serverVariable="RESPONSE_Set_Cookie" pattern="(.*SameSite=)(Lax|Strict)(.*)" negate="false" />
          <action type="Rewrite" value="{R:1}None{R:3}" />
        </rule>
        <preConditions>
          <preCondition name="No SameSite">
            <add input="{RESPONSE_Set_Cookie}" pattern="." />
            <add input="{RESPONSE_Set_Cookie}" pattern="; SameSite=*" negate="true" />
          </preCondition>
        </preConditions>
      </outboundRules>
    </rewrite>

  • This rule only adds the SameSite=None attribute if requests includes Chrome in the user agent. This is because not all browsers properly support SameSite=None yet. The rule also makes sure to add the attribute only if the SameSite attribute is not already available in the response. Refer the URL Rewrite documentation to construct conditions for other browsers’ user-agent strings
  • The rule also replaces any SameSite=Lax or SameSite=Strict values to prevent updates in the .NET framework to explicitly set the attribute and cause a breaking change again, for example with this update: https://support.microsoft.com/en-us/help/4532933/kb4532933-cumulative-update-for-net-framework

    Alternative Workaround 3: Postpone upgrade of your browser (K2 Five, K2 Cloud, K2 4.7)

    Administrators can prevent their users’ browsers from automatically being upgraded to the latest version. See Manage Chrome updates for information on this workaround for Chrome and resources such as How to disable edge auto upgrade? and  Blocker Toolkit to disable automatic delivery of Microsoft Edge for Microsoft Edge.