Skip to content
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

Merged
merged 7 commits into from
Feb 21, 2020

Conversation

hudajkhan
Copy link
Member

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

  • Other Relevant Links (Mailing list discussion, related pull requests, etc.)

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

@@ -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;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
import org.apache.jena.rdf.model.ResourceFactory;

Can this import be removed?

Copy link
Member

@gneissone gneissone left a 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.

@awoods
Copy link
Member

awoods commented Jan 14, 2019

@hudajkhan : would you mind creating a JIRA for this PR so that it does not get lost in the shuffle?

@gneissone
Copy link
Member

@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.

@awoods
Copy link
Member

awoods commented Jan 15, 2020

@brianjlowe ? @vivo-project/vivo-committers ? any comments on this bug fix?

@awoods
Copy link
Member

awoods commented Jan 23, 2020

@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 AddObjectPropertyStatement and AddDataPropertyStatement actions are unrecognized by any policy and therefore "INCONCLUSIVE".

My question is: What permission do we expect to be in the session that would recognized (and allow) the above actions?

@awoods
Copy link
Member

awoods commented Jan 24, 2020

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 #selfEditor update level.

Using the debugger, the edit requests on faux properties are declined due to the PropertyRestrictionBeanImpl returning nobody instead of selfEditor. When I change the value of these properties to "self-editor and above" in the Faux Property editor form in the "site admin"... the functionality appears to be correct.

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?

@gneissone
Copy link
Member

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.

@brianjlowe
Copy link
Member

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.

@awoods awoods closed this Jan 28, 2020
@gneissone
Copy link
Member

Reopening this pull request. In an effort to follow current best practices, the VIVO project will now be developed against the master branch. As a result of removing the develop branch, this pull request was automatically closed by GitHub, apologies for any confusion this may have caused.

@gneissone gneissone reopened this Feb 5, 2020
@gneissone gneissone changed the base branch from develop to master February 5, 2020 16:08
@brianjlowe
Copy link
Member

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:

predicateProp.setDomainVClassURI(EditConfigurationUtils.getDomainUri(vreq));
predicateProp.setRangeVClassURI(EditConfigurationUtils.getRangeUri(vreq));

I'll try to test this out when I get a chance.

@gneissone
Copy link
Member

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 We're sorry, but you are not authorized to view the page you requested. If you think this is an error, please contact us and we'll be happy to help.

@brianjlowe
Copy link
Member

Thanks, Benjamin. Turns out the domain and range were only part of it. This version appears to be working as expected:

    @Override
    protected AuthorizationRequest requiredActions(VitroRequest vreq) {
        //Check if this statement can be edited here and return unauthorized if not
        String subjectUri = EditConfigurationUtils.getSubjectUri(vreq);
        String predicateUri = EditConfigurationUtils.getPredicateUri(vreq);
        String objectUri = EditConfigurationUtils.getObjectUri(vreq);
        String domainUri = EditConfigurationUtils.getDomainUri(vreq); 
        String rangeUri = EditConfigurationUtils.getRangeUri(vreq);
        Property predicateProp = new Property();
        predicateProp.setURI(predicateUri);
        predicateProp.setDomainVClassURI(domainUri);
        predicateProp.setRangeVClassURI(rangeUri);
        OntModel ontModel = ModelAccess.on(vreq).getOntModel();        
        AbstractObjectPropertyStatementAction objectPropertyAction;
        if (objectUri == null) {
            objectPropertyAction = new AddObjectPropertyStatement(
                    ontModel, subjectUri, predicateProp, RequestedAction.SOME_URI);            
        } else {            
            if (isDeleteForm(vreq)) {
                objectPropertyAction = new DropObjectPropertyStatement(
                        ontModel, subjectUri, predicateProp, objectUri);
            } else {
                objectPropertyAction = new EditObjectPropertyStatement(
                        ontModel, subjectUri, predicateProp, objectUri);
            }
        }        
        boolean isAuthorized = PolicyHelper.isAuthorizedForActions(vreq, 
                new EditDataPropertyStatement(ontModel, subjectUri, predicateUri, objectUri).
                or(objectPropertyAction));
        if (isAuthorized) {
            return SimplePermission.DO_FRONT_END_EDITING.ACTION;
        } else { 
            return AuthorizationRequest.UNAUTHORIZED;
        }
}

@awoods
Copy link
Member

awoods commented Feb 10, 2020

@brianjlowe : Can you submit a pull-request against @hudajkhan 's branch:
https://github.com/hudajkhan/Vitro/tree/updateEditing

@awoods
Copy link
Member

awoods commented Feb 11, 2020

@brianjlowe / @hudajkhan / @gneissone : My local testing verifies Brian's PR both allows for self-edit of all properties, while prohibiting edit of other profiles.

@hudajkhan
Copy link
Member Author

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.
*
Copy link
Member

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?

Copy link
Member

@awoods awoods left a 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.

@awoods
Copy link
Member

awoods commented Feb 20, 2020

I believe @gneissone still has an outstanding "request for change"... which has likely been addressed.

@gneissone gneissone self-requested a review February 21, 2020 00:43
Copy link
Member

@gneissone gneissone left a 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants