First time visit to an item leads to an "Invalid CSRF token" when attempting to store usage event

[KevinVdV]

Describe the bug When you visit an community/collection/item page for the very first time (as in your first page on a repository) the POST to the "/server/api/statistics/viewevents" leads to a 403 with the following message:

Access is denied. Invalid CSRF token.

To Reproduce Steps to reproduce the behavior:

1. Install something like "Clear Session" or similar
2. Then visit a random item on the DSpace 7 demo site
3. Clear the sessions completely
4. Open up a network tab
5. Refresh the item page, at this point you are basically visiting the repo for the first time, no previous sessions or cookies, ...
6. The POST to the "/server/api/statistics/viewevents" WILL fail with a 403.

Ps: You CANNOT reproduce in an anonymous browser window, for whatever reason I do not get the issue there.

Expected behavior The POST should work as it does for subsequent requests. As it stands now people coming from a random google page that visit the repo will not have their first hits registered as statistics.

[tdonohue]

Hi @KevinVdV : Just wanted to note why this seems to occur (as I've seen it as well)

As you likely know, you receive a valid CSRF token (from the REST API) from the response from your first GET request. In this scenario, I believe this POST happens almost immediately after (or at the same time) as the first GET... so when the POST occurs, the client hasn't received a CSRF token yet, and therefore doesn't send the CSRF token with the first POST (resulting in the 403).

My only idea here would be to find a way to delay the first POST slightly until after the initial GET responds with the token. In general, maybe the POST for every viewevent should be delayed so that it doesn't occur until the GET for that same event receives a response...that should ensure the POST always succeeds, as if the CSRF token is new or changed by the GET, then it'll send that updated CSRF token in the POST.

I admit, I'm not exactly sure how to implement this on the Angular side, but I think that's what's happening here.

For now, I've moved this to the 7.2 board in case it's a simple fix. If so, I'm glad to try to get it into 7.2. If it's more complex though, then it's more likely we'd have to fix this in 7.3 (and anything unfinished on the 7.2 board will get moved to 7.3)

[tdonohue]

@benbosman : Another older ticket previously assigned to you / your team. Do you want this to remain assigned to Atmire for 7.5, or should I unassign?

[tdonohue]

Closing, as this was a duplicate of https://github.com/DSpace/DSpace/issues/9236 which has been fixed.