Bug #5551
closedSet public access button on the FGDC document display page doesn't work (on sanparks skin).
0%
Description
When I tried to grant a public readable access to a nonpublic readable document, i got an error:
User public does not have permission to read the document with the docid kepler_kepler.19.1
When i tried to revoke a public readable access from a public readable document, i got a message "null" on the top of the page.
Both documents still keep the original access rules after click the buttons.
Updated by Jing Tao about 13 years ago
The kepler_kepler_21 is a FGDC document with the public readable access rule. Here is the record on xml_access:
kepler_kepler.21 | kepler_kepler.21.1 | | public | 4 | allow | denyFirst |
After click the "Set Access" button with unchecked "public read" (revoking the public readable access rule), the parameters sent to the server are:
knb 20111123-13:56:21: [INFO]: Set access ------ docid kepler_kepler.21.1 [edu.ucsb.nceas.metacat.MetacatHandler]
knb 20111123-13:56:21: [INFO]: Set access ------ principal public [edu.ucsb.nceas.metacat.MetacatHandler]
knb 20111123-13:56:21: [INFO]: Set access ------ permission read [edu.ucsb.nceas.metacat.MetacatHandler]
knb 20111123-13:56:21: [INFO]: Set access ------ permtype deny [edu.ucsb.nceas.metacat.MetacatHandler]
knb 20111123-13:56:21: [INFO]: Set access ------ permorder allowFirst [edu.ucsb.nceas.metacat.MetacatHandler]
So, it will try to change the permOrder from denyFirst to allowFirst. But metacat doesn't allow to that:
[ERROR]: MetacatHandler.handleSetAccessAction - Error inserting permission: XMLAccessAccess.addXMLAccess - cannot add permission record for id: kepler_kepler.21with permOrder: allowFirst due to permOrder conflict [edu.ucsb.nceas.metacat.MetacatHandler]
So the change failed.
Updated by Jing Tao about 13 years ago
To a none-public readable document, if we click the set access button with the checked public read check box, the document will be granted a public readable access rule successfully. The rule has denyFirst perm order.
To a none-public readable document, if we click the set access button with the unchecked public read check box (this means revoking a public access from a document without public access), a user will get "User public does not have permission to read the document" error.
Updated by Jing Tao about 13 years ago
Since "setaccess" action can add access rules, this will cause problem.
Since the documents' allow rules for public reading always has denyFirst order type, there is no way to deny the read allow rule since deny rule will be applied first. We can't change the order type, we have to choose "denyFirst" or "allowFirst" at begin.
If we choose "allowFirst", then we can revoke the rule allowing public reading. However, we can't grant public reading allow rule again!
If we have delete access action, we can avoid this scenario. I will input a bug for that.
Updated by Jing Tao about 13 years ago
Also i noticed after set the access, the delete, update and set access button disappeared. Only download button can be seen. I think those buttons should be seen also.
Updated by Jing Tao about 13 years ago
For the issue on comment 4, I found the clientViewBean object wasn't set sesssion id in ClientViewHelper.java. After set it on the method clientRequest, then it works.
Updated by Jing Tao about 13 years ago
Now we had temporary solution for set/revoke public readable access:
user can grant public access to a document, then he can revoke it. After the revoking, the user can't grant the public access again.
In order to fix the issue, we need to fix the bug 5553.
I am going to close the bug and add a note on bug 5553 to indicate to open this bug when bug 5553 is fixed.
Updated by Jing Tao about 13 years ago
reopen this bug since ben added a comment on bug 5553:
There is currently a method in Metacat's access API that allows you to set the
entire access block for a given document instead of just adding them one by
one. This method effectively deletes all access rules and replaces them with
the one you specify in the call. I think you could use this method aslong as
you were careful to preserve the access rules that are for principals other
than "public".
The method uses the same "action=setaccess", but you include a complete
"accessBlock" parameter that is the XML representation of the access control
rules (like they are returned in the action=getaccesscontrol method). For
example:
http://knb.ecoinformatics.org/knb/metacat?action=getaccesscontrol&docid=tao.1.1
Updated by Jing Tao about 13 years ago
Use accessBlock parameter on setaccess action to replace the original access rules by the new access rules. The new access rules combine the preserved the original access rules which are not for user public and a allow or deny rule for user public.