Skip to content

Improve scoping checks for objects#7739

Merged
labkey-jeckels merged 7 commits into
release25.7-SNAPSHOTfrom
25.7_fb_scoping
Jun 11, 2026
Merged

Improve scoping checks for objects#7739
labkey-jeckels merged 7 commits into
release25.7-SNAPSHOTfrom
25.7_fb_scoping

Conversation

@labkey-jeckels

@labkey-jeckels labkey-jeckels commented Jun 9, 2026

Copy link
Copy Markdown
Contributor

Rationale

We can improve our parameter validation

Changes

  • New helpful base class for integration tests, AbstractContainerScopingTest
  • New test coverage
  • Assorted scoping checks

@labkey-jeckels labkey-jeckels marked this pull request as draft June 9, 2026 20:18
@github-actions

github-actions Bot commented Jun 9, 2026

Copy link
Copy Markdown

WARNING: This PR appears to have the default title generated by GitHub. Please use something more descriptive.

if (data == null)
throw new NotFoundException("Error: Data object not found for the given LSID: " + lsid);
// The LSID could be from another container. If so, redirect there
ensureCorrectContainer(getContainer(), data, getViewContext());

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

so if I understand ensureCorrectContainer correctly, it will redirect when a requested object is from a different container (and check that the user has read perm in that container). shouldn't some of the cases return "not found" in that case instead? for example, this usage of getting an attachment for a dataclass seems a bit odd to me that it redirects instead of telling the user the object wasn't found in the request container.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Yes, it's been that way for a while (aside from the next check to make sure that the user can see that container). It was originally because we weren't always great at using the right container in the URL when you have a grid of rows that span multiple containers via a non-default ContainerFilter.

We could choose to be stricter, but this is a way to continue to support sloppy links while fixing the real bug.


Container source = issue.getContainerFromId();
// Moving an issue removes it from its source folder, so require Admin there.
if (source == null || !source.hasPermission(getUser(), AdminPermission.class))

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

should this also be checking that the issue's source container is the same as the action/request container? I'm not seeing that check anywhere (but I'm not sure if this action is intended to support cross-container moves of issues).

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

It could be that picky, but this approach supports a grid with a non-default ContainerFilter so it seems like most backwards compatible approach.

assertNull("No study should have been created in the destination", StudyManager.getInstance().getStudy(dest));
assertNotNull("The source study must be untouched", StudyManager.getInstance().getStudy(source));

// Positive scenario covered by StudyPublishTest

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

is the "destination folder doesn't exist so check admin on the destination parent" check also new here? if so, should that have a test case?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Added

if (errors.hasErrors())
return false;

if (cSrc == null || !cSrc.hasPermission(getUser(), AdminPermission.class))

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I like that the comment "//user must have admin perms on both source and destination container" was already included above

return false;

if (cSrc == null || !cSrc.hasPermission(getUser(), AdminPermission.class))
throw new NotFoundException("No source container found, or you do not have permission to copy from it.");

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

this check on cSrc throws NotFoundException but below if the user doesn't have AdminPermission to _cDest, it just skips the if block and returns true. Should that check on _cDest also throw NotFoundException?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Yes, added

@labkey-jeckels labkey-jeckels changed the title 25.7 fb scoping Improve scoping checks for objects Jun 10, 2026
@labkey-jeckels labkey-jeckels marked this pull request as ready for review June 11, 2026 00:13
@labkey-jeckels labkey-jeckels merged commit 49800b1 into release25.7-SNAPSHOT Jun 11, 2026
14 checks passed
@labkey-jeckels labkey-jeckels deleted the 25.7_fb_scoping branch June 11, 2026 03:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants