Disable or hide created_by & updated_by

[derrickmehaffy]

• I have created my request on the Product Board before I submitted this issue
• I have looked at all the other requests on the Product Board before I submitted this issue

Please describe your feature request:

Currently with v3.1.x the default created_by and updated_by fields were added to every model. We need a way to disable these fields or at least hide them from the default REST/GraphQL API responses (similar to created_at and updated_at)

[lauriejim]

Ping @Aurelsicoko and @alexandrebodin.
Do you have a use case?
Because is you disable it, the RBAC feature will be impacted (you will not be able to manage stuff by author) :/

[alexandrebodin]

Yeah I don't see how we could disable this but more customization is totally possible in the generated APIs

[shea256]

Hi I'd like to second this.

My usecase:

I am maintaining a database where multiple authors will edit each object. I want to make the data available with a public API, but I don't want to reveal information about who has been creating and editing the objects.

Obfuscation is very valuable here.

[charshum]

It will be a bit strange when the API is publicly accessible where the public can know the author's name from the API

[oomixoo]

My case
I am using it with more than 1 database.
The program shows an error "strapi select distinct strapi_administrator doesn't exist ".

[derrickmehaffy]

@alexandrebodin I'm thinking just sanitizing it from the response would be the best case here, adding a similar boolean to the generated API schema (and keeing it disabled by default) then passing that through the sanitize function to remove it (or even better is not requesting it from the database to begin with, as that is going to decrease query time on the database)

[herrbischoff]

This is very similar to my planned use case.

I'm looking to replace an aging CMS using a separate frontend which consumes a public API. The API could be provided by Strapi. Multiple people are going to edit content and there is simply no need to see who's edited what. Additionally, it's simply careless to disclose more information than is necessary. This could also lead to GDPR and confidentiality issues as you're revealing names of people who edit content which in turn can potentially reveal relationships that you do not want to reveal.

I agree with @derrickmehaffy that the best solution would be offer the ability to filter out certain fields from the database request. I was actually surprised to find that currently no kind of output filtering is available.

For my use case Strapi is the first choice on all counts but the created_by and updated_by output is a hard pass criterion for exclusion. I'd also like to filter created_at and updated_at.

[weidox]

It's also a hole for hefty fines for GDPR, for disclosing user personal details. Priority should be high, not low.

[PascalHesselink]

My API will be available for public use, it's necessary to hide the created_by and updated_by fields in the output response of the API. The authors and maintainers of a record should be private in my case. I will upvote for a feature request to make this configurable through the UI/Admin panel per model. Same for the timestamps. It would be even better if you decide to make this configurable per route (find, findOne etc).

[derrickmehaffy]

@weidox and @PascalHesselink I hadn't actually considered the GDPR side of this when I originally opened the feature request but you do make a good point, though I am not familiar with GDPR laws as I am US based (and not a lawyer 😉 ) but since I have started working for Strapi now in an official capacity I have escalated the issue internally to our teams to see if there is at least a workaround for this or when we can expect something to solve this issue/feature request.

I'll keep you updated when I can get some more information 😃

[weidox]

It's enough to remove first and last names from created_by and updated_by, as that's the only private user information being exposed (I doubt if there was a technical reason to do that at all). The rest can remain, and probably that would not break anything then.
As of option for complete removal, the remaining data is not subject to GDPR as there's no user identifiable info remaining, so I doubt the usefulness. @PascalHesselink maybe you could collaborate more on that.

[Aurelsicoko]

As I'm managing all the GDRP topics in the company, we (as the legal entity behind the project) are still compliant with the GDPR regulation. The GDPR only applies to data that we own/store or we have access to. However, for you as users of the software, it's different. Some personal user information are shared publicly due to our current public API design.

I would suggest to not expose these fields in the Public API, but only in the Admin API (the administration panel need them). By default, we should apply filters that hide these fields to avoid any non-expected behavior and for some of you GDPR issues. However, it should be an option or something you can easily enable/disabled if needed.

However, if you enable the option or remove the filters that hide these fields, you'll have to make sure you've asked the consent of the administrators to expose their personal information. That's why, in my opinion, it should be an option because it will certainly require to add a checkbox asking for consent somewhere when a new administrator registers to the project.