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

Cannot apply field level access permissions on fields inside a nested object #399

Open
isaacchircop opened this issue Sep 13, 2018 · 2 comments

Comments

@isaacchircop
Copy link

I am trying to perform field level access on my resource fields by extending the ResourceFilterBase class as explained here. However, I am observing that the filterField() method is only being called for first level attributes of the corresponding resource.

As an example, let's say I have the following classes representing a Person object:

@JsonApiResource(type = "persons")
public class Person {
    private String name;
    private String surname;

    private Address address;
}

public class Address {
    private String addr1;
    private String addr2;
}

Performing field level access on either addr1 or addr2 is unachievable since the filterField() method would be only called 3 times, once for each field found inside the Person resource. I believe that since the address field is of a complex type, its fields should be filtered just the same, since a user may not have access to all its fields.

@remmeier
Copy link
Contributor

Yes, true. So far the top-level fields are hold as meta-model within ResourceInformation and ResourceField. There is so far no concept of nested/complex types as attributes. In general I think it would make sense to move into this direction. First step could be a @JsonApiEmbeddable or @JsonApiComplexType annotation just like in JPA and add the necessary information to ResourceInformation/ResourceField. A ComplexTypeInformation and ResourceInformation could then share a common super type. Once this information is available, in can be used in the various places, like security.

@jmhernandez127
Copy link

Hi @remmeier ,
Is there any progress for the issue fix please? We tested this on the latest crnk version but issue is still present.

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

No branches or pull requests

3 participants