[#4480] Only allow editing of your own ACLs
| Summary | Only allow editing of your own ACLs |
| Queue | IMP |
| Queue Version | HEAD |
| Type | Enhancement |
| State | Accepted |
| Priority | 1. Low |
| Owners | |
| Requester | Matt Selsky <selsky (at) columbia (dot) edu> |
| Created | 10/03/2006 (587 days ago) |
| Due | |
| Updated | 05/10/2007 (368 days ago) |
| Assigned | 10/03/2006 (587 days ago) |
| Resolved | |
| Attachments | myrights[1].patch  |
| Milestone | |
| Patch |
Taken from Matt Selsky
State ⇒ Accepted
See:
http://cvs.horde.org/co.php?r=1.28&f=framework%2FIMAP%2FIMAP%2FACL%2Frfc2086.php#l380
and
http://cvs.horde.org/co.php?r=1.28&f=framework%2FIMAP%2FIMAP%2FACL%2Frfc2086.php#l530
State ⇒ Feedback
Which login code is in question here? Is this still an issue?Committed. Login code still needs to be refactored.But technically, the username passed in the parameters is only an argurment for the driver instance, other drivers might not need this parameter.> Not at the moment, but given that this is a general purpose class in
> horde, I would like to keep that option.
The RFC doesn't seem to provide a mechanism to get this sort of information though...
> Are there cases when you'd want to call canEdit() for other users
> besides the current one?
Not at the moment, but given that this is a general purpose class in horde, I would like to keep that option.
Are there cases when you'd want to call canEdit() for other users besides the current one?> Neither, the method should be used as is, and you patch looks like it
> does this. I don't exactly follow the logic without applying the
> patch, but do you have in mind that the driver could connect as a
> regular user or the cyrus user?
> Beside that, that authentication stuff has to go into a separate
> private method to avoid the code duplication.
Currently the driver connects as a regular user. No special access is needed for the MYRIGHTS command. I'll refactor the authentication code.
> Or should the canEdit function be modified to make the $user argument
> optional, and if not set, then do the MYRIGHTS command above?
Neither, the method should be used as is, and you patch looks like it does this. I don't exactly follow the logic without applying the patch, but do you have in mind that the driver could connect as a regular user or the cyrus user?
Beside that, that authentication stuff has to go into a separate private method to avoid the code duplication.
New Attachment: myrights[1].patch
Let's try that again.New Attachment: myrights.patch
Comments?There's a canEdit($folder, $user) function that is unimplemented in all drivers. Any problem with adding a new function?
canUserEdit($folder) {
// ask IMAP server for rights on $folder via "MYRIGHTS" command for current user.
}
Or should the canEdit function be modified to make the $user argument optional, and if not set, then do the MYRIGHTS command above?
Summary ⇒ Only allow editting of your own ACLs
Priority ⇒ 1. Low
Type ⇒ Enhancement
Queue ⇒ IMP
State ⇒ New
IMP currently shows ACLs for folders that you don't have admin access to as if you can edit them. IMP should instead display the ACL, but grey it out so you don't think you can change it. Currently the error is "Permission denied" with Cyrus.