CSRF bugfix

[Atmire-Kristof]

References

• Fixes #9236
• REST side of this PR: #9368
• "7_x" REST side of this PR: #9369
• "7_x" Angular side of this PR: #2839

Description

This PR adds a /api/security/csrf endpoint to send POST requests to, which returns the appropriate CSRF headers/cookies, avoiding any subsequent POST request from failing before CSRF headers are set.

Instructions for Reviewers

Changes made:

• A new XSRFService will send out a POST request to the new csrf endpoint (browser-side, since server-side can only send GET requests)

For testing, I'd advise setting up both Angular and REST side of this PR (note, when referring to csrf cookie, I'm talking about "DSPACE-XSRF-COOKIE"):

• Load the homepage as anonymous and confirm a csrf POST request is sent to the new endpoint
• Confirm the first "statistics" POST request (should be "viewevents") contains the correct CSRF cookie and header and succeeds
• Confirm the same happens when logged in
• Using curl or any other method (e.g. Postman), copy the statistics request from your browser (containing equal valid CSRF header and cookie) and confirm the response DOES NOT contain the header and cookie
• Modify the request by removing the header, leaving only the cookie and confirm the response DOES contain the new cookie
• Modify the request by removing the cookie, leaving only the header and confirm the response contains the new cookie
• Modify the request by removing both cookie and header and once again, confirm it contains the new cookie
• Modify the request by changing the header/cookie to be different from each other and confirm it contains the new cookie

Checklist

This checklist provides a reminder of what we are going to look for when reviewing your PR. You need not complete this checklist prior to creating your PR (draft PRs are always welcome). If you are unsure about an item in the checklist, don't hesitate to ask. We're here to help!

• My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
• My PR passes ESLint validation using yarn lint
• My PR doesn't introduce circular dependencies (verified via yarn check-circ-deps)
• My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
• My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
• If my PR includes new libraries/dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
• If my PR includes new features or configurations, I've provided basic technical documentation in the PR itself.
• If my PR fixes an issue ticket, I've linked them together.

[github-actions]

Hi @Atmire-Kristof,
Conflicts have been detected against the base branch.
Please resolve these conflicts as soon as you can. Thanks!

[tdonohue]

@Atmire-Kristof and @artlowel : This has been replaced by #2886 (which was just merged). I cherry-picked the main commit from this PR (5f52e69) to fix a bug we were having in e2e tests (the e2e tests were having this same issue where the CSRF token was not always pre-initialized before the first non-GET request).

So, I believe this PR is now obsolete and can be closed. Your changes have been applied to main via #2886. That said, I'll leave this open until you have the chance to verify.

NOTE: I have NOT yet ported the changes to dspace-7_x as we'll need to discuss whether this new /api/security/csrf endpoint should be added to the 7.x codebase.

[tdonohue]

Closing as I've tested further and verified this is fixed by #2886