session-cookiessharepoint-onlineweb-partsprovider-hosted

SPO Provider hosted Client web part not storing session cookie


I have a provider hosted app which uses SharePoint Context filter for authenticating users. I'm storing the context token generated in the first request in a session variable and using it in subsequent calls.

When I click on the app in site contents and get redirected to the provider hosted app, everything is working fine.

But when I navigate to a page in SharePoint Online which has a Client Webpart hosted in the provider hosted app, session does not work.

On inspecting the request headers sent by the App webpart and the app when it is opened directly, I found that ASP.NET_SessionId cookie is not getting stored in the app webpart but when the provider hosted app is navigated directly.

Also I found that SPCacheKey cookie is being stored in both cases only Session cookie is not getting stored when loading via app web part.

I tested this in Chrome as well as IE and both are giving same output.

I tried modifying the web.config as per this link

  <system.webServer>    
    <httpProtocol>
      <customHeaders>
        <add name="p3p" value="CP=&quot;IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT&quot;"/>
      </customHeaders>
    </httpProtocol>
  </system.webServer>

But it didnt solve the issue. Because of the session not getting stored, Every ajax call in my provider hosted app is getting redirected to appredirect.aspx which is throwing

Access to xmlhttprequest at https://tenant.sharepoint.com from origin https://providerhosted.domain blocked by cors policy no access

Why is the ASP.NET Session Id cookie not getting stored when loading via app webpart? Please help


Solution

  • After searching solution for this problem using many different keywords in google, finally found a solution. It looks like this is an Iframe issue. As the app web part loads inside an iframe, the session cookies are not stored inside iframe.

    As per this answer and this link, adding the cookieSameSite=None attribute in the sessionState of web.config fixed the issue.

    <sessionState cookieSameSite="None"  cookieless="false" timeout="360"> 
    </sessionState>
    

    As usual, this was caused by an update release by MS which changed the default value of cookieSameSite attribute of Session cookies from None to Lax