View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
---|---|---|---|---|---|---|---|---|---|
0000295 | v1.2 Release (Closed) | [All Projects] General | public | 2009-10-28 14:29 | 2009-12-08 19:06 | ||||
Reporter | cheuschober | ||||||||
Assigned To | caseydk | ||||||||
Priority | high | Severity | major | Reproducibility | always | ||||
Status | closed | Resolution | fixed | ||||||
Product Version | |||||||||
Target Version | Fixed in Version | 1.2 | |||||||
Summary | 0000295: Task Access security circumvented by files module | ||||||||
Description | Our team decided to give W2P a test run the other day and discovered a disturbing little bit when trying to isolate files within tasks. Our consensus on the whole permissions issue was that while we'd prefer per-project permissions based on batch contact assignment we could work with the task access field to simulate that and protect information that can't be shared within the entire org (eg, something like a budget document with worker salaries). The assumption was that if a task is set to private/participant then files associated with that task would similarly inherit that access. Not only was that NOT the case we found that the associated task, as linked under the the files module completely bypasses the access check and allows any user straight into the participant/private task. I'm not certain if it's the intention of the devs to allow protected files the way I've described but the access bypass, at least, seems like something that needs addressing. Hope this helps. -C ps. +1 for excluding files who are attached to access-limited tasks | ||||||||
Tags | No tags attached. | ||||||||
Attached Files |
|
![]() |
||||||
|
![]() |
|
caseydk (administrator) 2009-10-30 10:01 |
Agreed and good point. |
caseydk (administrator) 2009-11-20 23:21 |
"The assumption was that if a task is set to private/participant then files associated with that task would similarly inherit that access." I've fixed this portion of this issue in r783. I still need to work on filtering the file list itself... |
caseydk (administrator) 2009-11-24 22:17 |
Closing this one because the required changes for the original request are complete. For the filtering of the file list, issue 0000284 covers it just as well. |
![]() |
|||
Date Modified | Username | Field | Change |
---|---|---|---|
2009-10-28 14:29 | cheuschober | New Issue | |
2009-10-30 10:01 | caseydk | Note Added: 0000560 | |
2009-10-30 10:02 | caseydk | Status | new => assigned |
2009-10-30 10:02 | caseydk | Assigned To | => caseydk |
2009-10-30 10:02 | caseydk | Project | v1.1 Release (Closed) => v1.2 Release (Closed) |
2009-11-09 21:52 | caseydk | Relationship added | related to 0000284 |
2009-11-17 20:42 | caseydk | Priority | normal => high |
2009-11-20 23:21 | caseydk | Note Added: 0000596 | |
2009-11-20 23:21 | caseydk | Status | assigned => confirmed |
2009-11-24 22:17 | caseydk | Status | confirmed => resolved |
2009-11-24 22:17 | caseydk | Resolution | open => fixed |
2009-11-24 22:17 | caseydk | Note Added: 0000601 | |
2009-12-08 19:06 | caseydk | Status | resolved => closed |
2009-12-08 19:06 | caseydk | Fixed in Version | => 1.2 |