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

JsonIgnore issue #130

Open
andye2004 opened this issue Apr 29, 2018 · 2 comments
Open

JsonIgnore issue #130

andye2004 opened this issue Apr 29, 2018 · 2 comments

Comments

@andye2004
Copy link

I have an issue where I am trying to produce a schema for an object that has a password field. Obviously the field should be write-only and never be be serialised so it is marked as such in the entity but when I try to create the schema the field is omitted completely.

I have tried all of the following but they all result in the same outcome, no password field in the schema.

@JsonProperty(access = JsonProperty.Access.WRITE_ONLY)
private String password;
@JsonIgnoreProperties(value="password", allowSetters = true)
class User {
    private String password;
}
class User {
    @JsonIgnore
    private String password;

    @JsonIgnore
    public String getPassword() {
        return password;
    }

    @JsonProperty
    public void setPassword(String password) {
        this.password = password;
    }
}

I think that from a schema perspective the field should be defined as it is write-only and and clients of the service will need to send the field under different circumstances. I'm guessing this has something to do with the underlying use of jackson databind module but can you give any advice on how to achieve the desired outcome?

Thanks, Andy.

@cowtowncoder
Copy link
Member

Is there a concept of write-only in schema? Can you give an example of expected schema, along with what is currently produced?
I suspect that as things are now, Jackson-side concept of read-/write-only, which is relatively new addition, is not being exposed (or not used) by JSON schema module.

@andye2004
Copy link
Author

andye2004 commented Apr 29, 2018

@cowtowncoder wow, thanks for such a fast response! Unless I'm mis-reading it, Section 10.3 of the spec defines the concept readOnly and writeOnly however for my purposes I'd be happy to simply have the field present in the schema as a normal schema property. This should be enough for clients to generate payloads containing the field as required by the server.

An example would look something like:

{
  "type" : "object",
  "id" : "User",
  "properties" : {
    "password" : {
      "type" : "string"
    }
}

So just a normal StringSchema with no special decoration.

From what I can see of a cursory read of the source the field itself isn't exposed as opposed to not being used, given this I could add a 'post-processor' that would add the field back in based on the annotations. I'm already doing something similar for java.time.Instant fields but I was hoping there would be some simple way of doing this.

EDIT: Actually, that was a draft of the next release I was reading. So it seems the concept is coming but not yet here 😄. Full draft can be found here with release notes here

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

2 participants