[Building Sakai] BaseSiteService: is this a bug?
Zach A. Thomas
zach at aeroplanesoftware.com
Tue Mar 17 12:36:58 PDT 2009
Hello, all. I'm working on some pseudo-hierarchical features of Site
Info, and I ran into a snag which may or may not be BaseSiteService's
fault.
The basic idea is that from within Site Info, the site maintainer can
click to create a child site of that site. For permission, we give
this role "site.add" within that site, but not globally. In other
words, they do not have permission to create sites from Worksite Setup
in "My Workspace."
Here's where the problem comes in: in BaseSiteService, public Site
addSite(String id, Site other) performs the following permission check:
unlock(SECURE_ADD_SITE, siteReference(siteReference(id)));
"id" in this case is the site ID of the Site we're just about to
create. Since it doesn't exist yet, there's no way for my user to have
"site.add" on it. The only reason this works at all in Sakai is that
the typical User has been granted "site.add" by their user type (e.g.
"registered"). To prove to myself that the id passed into this check
is irrelevant, I changed it to "foobar" and sure enough, the
"registered" user passes the check, while my poor site maintainer is
held to an impossible standard.
It does what I want if I change it to check the id of the site _from
which_ I am making this call:
String currentSiteId = ToolManager.getCurrentPlacement().getContext();
unlock(SECURE_ADD_SITE, siteReference(siteReference(currentSiteId)));
This form of permission check also takes place in the
allowAddSite(String id) and addSite(String id, String type) methods.
Would it be reasonable to patch this and merge it to the 2.5.x branch?
I would add a check that getCurrentPlacement() is not null, but other
than that, any concerns?
cheers,
Zach Thomas
Owner, Aeroplane Software
More information about the sakai-dev
mailing list