David M Johnson wrote:
I think this bug can be fixed by changing RollerAtomHandler's
canEdit() method to this (I changed the comment too).
/**
* Return true if user is allowed to create/edit weblog entries
and file uploads in a website.
*/
private boolean canEdit(WebsiteData website) {
try {
UserData user = mRoller.getUser();
return website.hasUserPermissions(user,
PermissionsData.AUTHOR);
} catch (Exception e) {
mLogger.error("ERROR: checking website.canSave()");
}
return false;
}
That would work because ADMINs have AUTHOR permission.
yes, i agree ... if it's the case that admins implicitly have author
permissions. for example, if i add a permission data entry specifying a
user has admin rights, would the check above succeed? i assume so based
on what you said. i don't understand the details here.
for example, the AAPP code allows someone to add only the admin
permission w/o the author permission. do the system internals munge this
to reflect that the user has both author and admin?
Further comments below...
On Feb 28, 2006, at 3:33 PM, Jeff Blattman wrote:
okay ... then the code in RollerAtomHandler is incorrect then. the
APP code is rejecting GET access to the weblog if the user has only
authoring rights. i do not think this is correct. the impl of
RollerAtomHandler.canView() calls canEdit(), which calls WD.canSave()
... ?
I'm not sure we need separate canView() and canEdit() methods. You
have to be an AUTHOR or an ADMIN to use APP in Roller, and if you can
edit you can certainly view.
agreed.
but something to consider. does it make sense to have to endpoints that
allow a GET of the atom feed? different code? maybe that's a side effect
of APP being in sandbox right now.
i agree, a user shoud not be able to modify WD w/ only authoring
rights. however, consider the correctness of canSave() and
hasUserPermissions(). canSave() calls
hasUserPermissions(AUTHOR|ADMIN). if AUTHOR has nothing to do w/ the
check, then why is it being tested in the call? also, if the intent of:
hasUserPermissions(AUTHOR|ADMIN)
to check if the user has AUTHOR or ADMIN, or AUTHOR and ADMIN? if
it's the latter, then the code is correct. if it's the former, then
the code is wrong.
The pipe should mean AUTHOR OR ADMIN.
then i think the implementation is incorrect, for the reasons i
indicated in previous mails. for example, if your canEdit() code above
called this:
return website.hasUserPermissions(user,
PermissionsData.AUTHOR*|ADMIN*);
it would fail for authors. which is the root cause of my problem here.
it is probably risky to change the semantics of hasUserPermissions(), as
other code may be depending on it working as it does.
firstly, i would suggest that WD.canSave() should be modified to pass
in only the ADMIN flag, not AUTHOR. secondly, the implementation of
canView() in RollerAtomHandler needs to change. i am not exactly sure
what to check here. a blog can be viewed by anyone, right? so why do
a check at all in that case?
or, is it the case that you expect that the APP endpoint is only for
admin access, and clients should go through the atom endpoint for
read-only access? i hope not. that would require APP clients to be
configured w/ two endpoints.
The RollerAtomHandler is only for APP, only for AUTHORs and ADMINs and
only for editing blogs.
Other users access Atom feeds via the Atom servlet (mapped to /atom).
Does that make sense or am I still missing something?
agreed ... as long as the author case works. but like i said, it's be
nice to share the GET code at some point. i am obsessed with avoiding
code duplication :)
