How to hide properties of an ASP.NET Core model entity only in JSON rendering?

Asked

Viewed 512 times

1

I am starting studies with ASP.NET core Web Api, and am implementing the User class, which has a Password property. Logically I don’t want the password to be visible in the Jsons of the api.

I’ve been doing a lot of research, read about Ignoredatamember, Datacontract, Datamember etc... but their behavior is a little too radical, IE, when I add an Ignoredatamember annotation in the password property it does not display the password in the User object, but also cannot bind the User Password property when it comes in a POST request for example.

I would like a way that this property does not appear in the response JSON, but is still available for use within the system.

Before concluding, I know the Viewmodel standard, and I know I can create a class with only the parameters I want to display, but honestly, I find this project pattern extremely verbose (it’s too wordy to implement). I know I’m ultimately going to use it myself, but I’d like to have another more elegant option.

Thank you for your attention!

  • You have the code that generates that return?

  • The ideal is that you do not even store the password informed to the user and create a hash at the time of registration, for example the MD5 login + password... and it would be this result that you would use to validate if the data that the user inputou match the registration you have.

  • I believe that the ideal is for you to use Viewmodel to take to your view only the fields that should be shown and when you return you can use autommaper to transform to the model. Vou: Click Here

  • use the [Jsonignore] Assembly Newtonsoft.Json

  • @Leandroangelo, yes, I already do a hash from the user’s password, however, not even this hash I would like to display, since it can be used for searches in passwords databases md5 decrypt style (I know it is not a decryption, but a database search)

  • @Marconciliosouza, in this case, ASP.NET Core uses its own parser for the return, and frankly I would not like to change it, since the idea is to use the framework as pure as possible. Adding Newtonsoft was considered, but is not currently in the project.

  • @Rodrigoportilio, yeah... I’m coming to the same conclusion, although I still think that Viewmodel is an extremely verbose model of coding, since I have to basically clone the user entity just to remove a property. In the future, whenever a new property appears, that’s two more places to adjust. If you do so, I believe that I will not use the Automapper, since the system is expanding, it is necessary to change the mappers to each new entity implemented.

Show 2 more comments
No answers

Browser other questions tagged

You are not signed in. Login or sign up in order to post.