Timeout After 30 Minutes - "The security validation for this page is invalid and might be corrupted"

[LastGunslinger]

Thank you for reporting an issue, suggesting an enhancement, or asking a question. We appreciate your feedback - to help the team understand your
needs please complete the below template to ensure we have the details to help. Thanks!

Please check out the Docs to see if your question is already addressed there. This will help us ensure our documentation covers the most frequent questions.

Category

• Enhancement
• Bug
• Question
• Documentation gap/issue

Version

Please specify what version of the library you are using: [1.14.0]

Please specify what version(s) of SharePoint you are targeting: [SharePoint Online]

If you are not using the latest release, please update and see if the issue is resolved before submitting an issue.

Expected / Desired Behavior / Question

When setting up an SPFI object using the method shown in the documentation below, the context is invalidated after 30 minutes. Any POST requests after that time result in an HTTP 403 error - "The security validation for this page is invalid and might be corrupted". This was not an issue in v2 of the library, and I believe, but am not sure, that it was even working correctly in early versions of v3. This should constitute a bug and not just a breaking change between versions 2 and 3, since this is entirely separate behavior, even taking into account the fact that there is no longer a global sp object.

Observed Behavior

The app context is timed out and the user has to refresh the page to clear the error.

Steps to Reproduce

Create an app using PnPJS v3.2.0 and set up an SPFI object using this code from the documentation. If the user leaves the SP page for more than 30 minutes, they will receive the error when returning.

I'm opening this issue because I believe issue #2186, which refers to the same problem, was closed in error. It was noted in that issue that this problem was corrected in version 3.2.0, but I am still able to reproduce it in 3.2.0. There is a workaround proposed in that ticket, but a workaround is not a solution. If there is no plan to fix this issue and the workaround is the only solution that will be provided, please update the v3 documentation to reflect this, since users who were already using v2 will have this issue when they migrate.

const sp = spfi().using(SPFx(this.context))

[juliemturner]

#2188 is the PR that fixed the issue, so I'm assuming you're referencing the issue referenced #2186. Assuming yes, then no, the issue was not closed in error. The "workaround" that person "proposed" would have absolutely nothing to do with the token not being refreshed as that is just a different way to do the same thing... so why it is ok for them when doing it that way I can't say as there isn't enough code to even begin to speculate.

If you are experiencing an issue, please share a sample in a cloneable repository that demonstrates how you've architected your solution so that we can try and validate where the problem is, and we'll attempt to assist you.

[LastGunslinger]

@juliemturner I've edited my original comment to include the correct link. I'm working on a pared-down reproduction that should be ready in around 30 minutes. To expand on the original comment as well, I'm pretty sure that the only reason that more people aren't seeing this issue is that my use case involves re-querying for stale data from SharePoint using the react-query library.

Data is fetched from SP using the PnPJS library and cached using react-query. After 5 minutes, the data is considered stale, and if it needs to be used by the app again it is re-fetched from SP instead of the cached value being used. This all works fine unless the user has been away from the app for more than 30 minutes, in which case the app tries to re-fetch the data but isn't able to because the of the security token being invalidated. It is quite common that our users will do this, since we have a lot of very large forms that users need to fill out that often require looking up data in other areas or on other sites, so it isn't uncommon that a user will start a form, then navigate away for an extended amount of time, then come back to it later.

I'm also quite sure that this is an issue only with the v3 version of this library, as I have been using the same general method since we started using SPFx and PnPJS over 2 years ago.

[LastGunslinger]

@juliemturner - Here is a link to the the repo where I have reproduced this error. After doing more testing in a limited environment, I can consistently reproduce the error when using the sp.utility.resolvePrincipal function in the @pnp/sp/sputilities module. When that function is called, I can see an HTTP POST request to https://my-sp-site/_api/SP.Utilities.Utility.ResolvePrincipalInCurrentContext, which initially returns a 200 response, but returns a 403 after the 30 minute timeout.

In the linked repository, the main branch reproduces the issue, while the version2 branch does essentially the same thing, just using v2 of the PnPJS library. The rest of the code is just a standard web part scaffolded using the Yeoman generator as described here. I only made some slight changes to allow using React hooks.

[bcameron1231]

Hi @LastGunslinger Thank you for adding the repository. I am going to pick up this issue and I will work on your repro and hope to have some information back to you tonight or tomorrow. Appreciate the patience.

[bcameron1231]

@LastGunslinger Quick update for you.

I have reproduced the formsDigest timeout behavior using your main branch in your repository (Thank you!). I have isolated the issue to a specific area of code where the PnPjs SPFx behavior is grabbing legacyPageContext digest value with a new expiration, instead of creating a new one.

This issue only occurs when the spfi() object and spfx behavior is instantiated multiple times during the lifecycle of a web part.

Our general recommendation is to create your spfi() object once and re-use it in your web part. i.e, In a global scope such as the init method of your Web Part and pass that down to your components. In your code, you pass down the entire WebPartContext and you are re-creating the spfi() object inside your hook, which means it's constantly being re-created. Doing so is not a design pattern we recommend, and we will be adding better documentation around this.

Additionally I personally think you may want to re-consider passing an entire WebPartContext object around in your solution where possible.

---

We do believe this could be classified as bug and we are working address this issue. We have a planned release for Friday and hope to have a fix in place.

However, my recommendation to address this issue is to not create your spfi() object in your hook, but to instead create it in a global place such as your init() and pass it down to your functional component for re-use in your hooks.

[LastGunslinger]

@bcameron1231 Thanks for getting back with me so quickly! I'll definitely try out your suggested solution by creating only one instance of the SPFI object and re-using it. In your opinion, would this scenario work?

1. Create an SPFI object in the init() function of the web part
2. Pass that object to the parent app component on render and store it as global state (most likely using React Context)
3. Reference that global state directly in sub-components as opposed to passing it down as a prop

I'm asking because I'm trying to avoid re-architecting my existing applications to add the SPFI object as a prop to all of them.

EDIT:
I also wanted to add that when using SPBrowser(context.pageContext.web.absoluteUrl) instead of SPFx(context) when setting up the SPFI object, this is not an issue. Functionally, what is the difference between them if the app is only being consumed inside of SharePoint?

[bcameron1231]

Hi! Yes, this would work to put it on a Provider Context, and a pattern I have done in the past!

The only thing I'd probably mention, unrelated to this specific issue is as you develop your solution out, be very cognizant of how you are using your Contexts. They are great for sharing across components, but they also greatly reduce re-usability of components as you'll always need that context provider wrapping your children components.

Imagine a scenario where you want to move components into a re-usable library for all of your future customizations or web parts, you've now made a hard dependency on your components to always be a consumer of a context. Where as if you were passing as a prop, it enforces that dependency without bringing in any extra context values which may be unrelated (or even exist) to the new component you're building.

Does that make sense?

---

Answer to your update -- SPBrowser initlializes the RequestDigest hook differently. The SPFx() behavior initially pulls the context from the legacy digest when you instantiate it. This is where the issue ends up happening where we aren't properly calculating the expiration of that legacy digest value when it's being instantiated over and over again.

[LastGunslinger]

@bcameron1231 Thanks for the feedback and clarification on SPFx() vs. SPBrowser(), I really appreciate it.

I also appreciate the advice on using contexts. In our applications we've abstracted our component logic into hooks, and it's the hooks that depend on the context, but I understand your point and it is valid. For our use cases, a bit of coupling is generally acceptable, mainly because it's generally understood that these components won't be used outside of SharePoint (we're the SharePoint team, and the only team currently using React), and PnPJS is used in just about every single one of our apps, since interacting with SharePoint is their main goal. I can see how this could be a hindrance though, especially if we were to branch out.

[github-actions]

This issue is locked for inactivity or age. If you have a related issue please open a new issue and reference this one. Closed issues are not tracked.