Ticket #976 (closed Defect: worksforme)
dm4-accesscontrol utility: check if username is owner of workspace
Reported by: | Malte | Owned by: | |
---|---|---|---|
Priority: | Minor | Milestone: | Release 4.8.1 |
Component: | DeepaMehta Standard Distribution | Version: | 4.8 |
Keywords: | Cc: | jri | |
Complexity: | 2 | Area: | |
Module: | deepamehta-workspaces |
Description
As plugin developers we should be able to treat the owner of a workspace as an implicit member, we need a method to find out if a given username is the owner of a workspace. Otherwise we would artifically (for reasons of consistency) need to manually create a "Membership" association for the owner to the workspace as well.
Or we could also fix it directly and say that
AccessControl.isMember()
does not meet this needs.
See
https://api.deepamehta.de/deepamehta/4.8.1-SNAPSHOT/de/deepamehta/core/service/accesscontrol/AccessControl.html#isMember(java.lang.String,%20long)
Thanks for your support.
Change History
comment:2 Changed 9 years ago by Malte
- Status changed from new to closed
- Resolution set to worksforme
The "getWorkspaceOwner" of the AccessControlService? works for me. I thought it would not work because it is also called for requests (and logged in users) who should have a READ permission (Collaborative, Non-Member) on the workspace checked... But no AccessControlException? is raised, so this actually works fine.
comment:3 Changed 9 years ago by Malte
I was wrong and my initial thoughts correct, sorry. I just tried it again and can confirm this now. So the current API does NOT work for me because this isAuthorized check is also necessary for users who have no READ permission for the respective workspace. The task in question is, in this case, is the requesting user owner of this workspace.
comment:4 Changed 9 years ago by Malte
Ah, wait...
So, you mean, if hasReadPermission(currentUsername, confidentialWorkspaceId) returns false the current request/username can not be the workspace owner, is that your suggestion on how to implement my check? And if user has any read permission to a collaborative or confidential workspace topic she is either member or owner, right?
comment:5 Changed 9 years ago by Malte
Hahah, no, a soution looks still different... of course i cannot check if a user hasReadPermission as i could never know the ID of the workspace topic to check ... So, my permission check now actually catches a RuntimeException caused by an AccessControlException and if that is thrown, my user has (obviously no read permission and subsequently can not be the owner of the workspace...
OK, so this is safe and working now. Thanks anyways.
comment:6 Changed 9 years ago by jri
Initially you wrote:
we need a method to find out if a given username is the owner of a workspace
Here I understand you have a workspace ID at hand.
But then you write:
i could never know the ID of the workspace topic to check
Sorry, this seems contradictory to me.
I don't understand your recent comments.
What do you try to achieve?
Why do you think my suggestions will not work?
Fact is: the methods I've mentioned that take a workspace ID do work also if the user has no READ permission for that workspace.
comment:7 Changed 9 years ago by Malte
we need a method to find out if a given username is the owner of a workspace
Here I understand you have a workspace ID at hand.
But then you write:
i could never know the ID of the workspace topic to check
Sorry, this seems contradictory to me.
---
The issues was created while I was working with 4.7 and there i could never know the ID of the workspace. Upgrding to 4.8.1 (as you suggested in #978) did solve the issue for me.
What do you try to achieve?
AccesControl.isMember(user, workspaceId) to return true for the owner (without a membership) of the workspace too.
Thanks for your comments.
To get the owner of a workspace you can use the AccessControlService:
DM never creates a Membership for the workspace owner as this would be redundant.
When it comes to checking permissions the developer would normally not check ownership/membership manually but rely on the AccessControl high-level methods, e.g.
and new as of (upcoming) DM 4.8.1:
Does this help your case?