PKP Bugzilla – Bug 5620
Consider authorizing files as well as monograph in submission file grids
Last modified: 2011-08-25 11:10:05 PDT
We are moving to Git Issues for bug tracking in future releases. During transition, content will be in both tools. If you'd like to file a new bug, please create an issue.
The second (metadata) tab of the author submission file upload modal (index.php/ip/$$$call$$$/grid/files/submission-files/submission-files-grid/edit-metadata?gridId=grid-files-submissionfiles-submissionfilesgrid&fileId=2) is blank due to an authorization failure.
Hi Matt, it looks to me as if the policy needs tweaking. It has been written for monograph authorization not for file authorization because that wasn't in the spec. I'm not 100% sure how to implement this. I'd have to know more about the use case of this handler. Juan says he's going to discuss this with you tomorrow. He already implemented quite some policy changes by now. I'm also happy to join in to your discussion so we find the best solution for that problem.
Should point out, the policy is failing because there is no MonographId provided. If you simply add the monographId parameter to the URL that is used to load that form, then it will work.
However, we still have to think about authenticating the fileId to make sure the file is valid and that the user has permissions on that file.
I've been playing around with policies on the author pages and still not 100% satisfied with what I've got. We'll discuss.
Good point, Juan. Authorizing the monograph is probably a good idea anyway. Then you can also check whether the file really belongs to the given monograph for even better consistency.
still need to consider authorizing the file. leaving open until its considered and implemented. changing bug name.
I've analyzed this to find out what needs to be done:
1) We first need to identify all handler operations that operate on a single file or on file-workflow-level (as opposed to submission-level or submission-workflow-level). We also have to define whether a new authorization context object should be added (probably yes, but to which key) and from which DAOs we get that object.
2) We then have to extend the OMP permission spec with that information.
3) Based on 1) and 2) I can implement one or more file access policy/ies. If we have a mixture of file-only authorization and file-workflow-stage authorization then it will be easier to write a file authorization policy that we'll drop in dynamically in the authorize() methods for the operations identified in 1) in combination with the normal submission-level or workflow stage policies. One of the lessons learnt with respect to policies is that to avoid code duplication and to keep the policies simple it is sometimes better to have more than one policy in a single authorize() method, especially when it helps to reduce the number of overall policies required where multiple inheritance hierarchies exist.
4) Finally I can place the right policies in all handlers identified in 1)
I can do most of this on my own but 1) is much faster done together with the original author of the file grids who knows which operations require what. Otherwise I'll have to understand all these operations in detail myself. I'd like to have a call with the original author for step 1) and draw the necessary information together. Which grids are concerned? Who implemented these grids?
Juan, Matt just told me that he can provide the list of handler operations I need. (Thanks Matt!)
I forgot to put a link to Matt's document in here: https://spreadsheets.google.com/ccc?key=0At06yC5UhpezdG5YTWR2V1lfLWdxNjloeVMyd3dubWc
I'll probably tackle this as soon as I'm done with the meta-data stuff (only #5944 is missing there).
alec, turning this over to you.
Maybe relevant? https://spreadsheets.google.com/spreadsheet/ccc?key=0At06yC5UhpezdG5YTWR2V1lfLWdxNjloeVMyd3dubWc#gid=0
File authorization is now in place. May need fine-tuning on a case-by-case basis.