-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
authorization update for self editors #106
Conversation
@@ -13,11 +13,15 @@ | |||
|
|||
import org.apache.commons.logging.Log; | |||
import org.apache.commons.logging.LogFactory; | |||
|
|||
import org.apache.jena.ontology.OntModel; | |||
import org.apache.jena.rdf.model.ResourceFactory; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
import org.apache.jena.rdf.model.ResourceFactory; |
Can this import be removed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is working, but I think it is possible it's working a little too well. I am not able to add or edit any faux properties as a self-editor.
@hudajkhan : would you mind creating a JIRA for this PR so that it does not get lost in the shuffle? |
@hudajkhan I have not forgotten about your efforts. I wonder if @brianjlowe could help us here? I know at the very least he has leveraged VIVO's permission code before. @brianjlowe this was previously discussed via the committers channels, happy to clarify the issue if anything is not clear. |
@brianjlowe ? @vivo-project/vivo-committers ? any comments on this bug fix? |
@hudajkhan / @gneissone : While reproducing the behavior of a self-editor not being able to edit their own faux property, I captured the DEBUG log: https://gist.github.com/awoods/157eab4ab31b844be014669ac374915b It appears that both My question is: What permission do we expect to be in the session that would recognized (and allow) the above actions? |
Investigating further, @hudajkhan 's logic appears to work as expected (user can update their own profile, properties and faux properties... and not other profiles) only when the base-property from which the faux property is created has a Using the debugger, the edit requests on faux properties are declined due to the PropertyRestrictionBeanImpl returning I would expect that the appropriate changes could be made in vitroAnnotations.n3 as well. The remaining question is, are these properties' "prohibitedFromUpdateBelowRoleLevelAnnot" values set to "nobody" for some other reason? |
The authorization code should respect the settings in PropertyConfig.n3, right? The editing levels for each individual faux property need to be controlled separately, even if they share a base property. |
Benjamin is correct. Faux property visibility and editing levels override those of their parent property. It is a common occurrence that very generic base properties like "relates" are set to nobody (i.e. only root) while the more specific faux properties have greater visibility and editability. |
Reopening this pull request. In an effort to follow current best practices, the VIVO project will now be developed against the |
After taking a quick look at this, I think the problem is that predicateProp doesn't have its domainVClassURI and rangeVClassURI values set so that it can be recognized as a faux property if applicable. If we're lucky, it may be just a matter of adding after line 73:
I'll try to test this out when I get a chance. |
Thanks for taking a look @brianjlowe. Unfortunately I'm still not able to edit faux properties with the change. I get redirected to the home page and an error is displayed |
Thanks, Benjamin. Turns out the domain and range were only part of it. This version appears to be working as expected:
|
@brianjlowe : Can you submit a pull-request against @hudajkhan 's branch: |
@brianjlowe / @hudajkhan / @gneissone : My local testing verifies Brian's PR both allows for self-edit of all properties, while prohibiting edit of other profiles. |
The file has been updated based on suggestions from Brian Lowe and Benjamin Gross |
@@ -43,71 +51,101 @@ | |||
* by the N3 editing system. It will examine the request parameters, determine | |||
* which form to use, execute a EditConfiguration setup, and evaluate the | |||
* view indicated by the EditConfiguration. | |||
* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hudajkhan : there are a lot of whitespace changes that clutter this pull-request. Would you be able to limit the updates to the functional bits?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works as expected. I would be happy to merge now... unless anyone else would like to review first.
I believe @gneissone still has an outstanding "request for change"... which has likely been addressed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works as intended, thank you Huda and Brian.
Thank you for submitting a pull request! Title this pull request with a brief description of what the pull request fixes/improves/changes. Please describe the pull request in detail using the template below.
No linked JIRA issue:
We didn't create a specific JIRA issue although discussed this using other channels
What does this pull request do?
Ensures self-editors cannot access edit or add links using URLs
What's new?
The code which checks authorization now adds a check to see if this particular property can be edited or added for the current user. This check adds to the front end editing permission check.
How should this be tested?
I tested this using the following steps: When logged in as a site admin, I copied the URLs for adding and editing a data property and an object property. I then logged out and logged back in as a self editor and then tried to access these URLs. The page should not allow the form to display but should state that the user does not have access to this page.
Additional Notes:
Additional testing would be preferable for more editing scenarios across different roles.
Interested parties
@VIVO-project/vivo-committers and specifically @gneissone and @j2blake