Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(history): handle sanitization when fetching versions #20212

Merged
merged 19 commits into from Apr 30, 2024

Conversation

markkaylor
Copy link
Contributor

@markkaylor markkaylor commented Apr 25, 2024

What does it do?

  • Adjust history sanitization so it doesn't break the e2e tests
  • Build media and relations object in their own dedicated functions

How to test?

  • The e2e tests for history should pass (locally I have them passing as before they were broken, here in the CI they are sometimes flaky but I think it is unrelated)
  • History versions and their relations should not return sensitive data
  • Verify everything is working as normal (missing relations, restoration, etc...)
  • Admin user relations should not be completely sanitized out of the response

Copy link

vercel bot commented Apr 25, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
contributor-docs ✅ Ready (Inspect) Visit Preview 💬 Add feedback Apr 30, 2024 8:18am

@Marc-Roig
Copy link
Contributor

I would rather not tie data population with sanitization if possible, and looking at this situation, would it be possible to keep the entry structure the same (without the results & meta object wrapping it) , and keeping a context of missing relations?

@markkaylor
Copy link
Contributor Author

I would rather not tie data population with sanitization if possible, and looking at this situation, would it be possible to keep the entry structure the same (without the results & meta object wrapping it) , and keeping a context of missing relations?

I would be very interested in refactoring to find a better solution in an immediate follow up PR, but I was thinking of this PR as a patch to fix failing e2e tests currently on v5/main.

I also have this PR open that refactors history quite a bit: #20179 as well, so it might be nice to have that before making big changes here.

wdyt? Would you prefer I handle the refactor now on this PR?

@Marc-Roig
Copy link
Contributor

sounds good to me to move this forward to fix the e2e 🥳

Comment on lines +84 to +86
createdBy: version.createdBy
? pick(['id', 'firstname', 'lastname', 'username', 'email'], version.createdBy)
: undefined,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

arent the creator fields already inside the version data?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are omitting them as well 🤔 :

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we need to omit it if we are readding it again here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@remidej do you remember why we omit this in data and then return it here in the response?

const relatedEntry = await strapi.db
.query('plugin::upload.file')
.findOne({ where: { id: entry.id } });

if (relatedEntry) {
currentRelationData.results.push(relatedEntry);
const sanitizedEntry = await permissionChecker.sanitizeOutput(relatedEntry);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder why you picked this in the end and not mainfield only population

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here for upload I don't think a mainField is available 🤔 but maybe it is. For the other instance with relations I did test it out but I think I abandoned it quite quickly when values weren't showing up as expected. I'll try it again real quick.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as you want I'm just curious, don't want to block you. And I doubt sanitization is needed on media assets

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good, I might just merge this now then and circle back to the idea in another PR with some of the refactor ideas.

@markkaylor markkaylor merged commit 4a26739 into v5/main Apr 30, 2024
79 of 83 checks passed
@markkaylor markkaylor deleted the fix/history-tests branch April 30, 2024 09:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pr: fix This PR is fixing a bug source: core:content-manager Source is core/content-manager package
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants