Closed Jahorse closed 1 year ago
Hello @Jahorse,
Thanks for flagging this out. I'll take it for next version. Proposed solution is by default id
to be returned and all other fields optionally using populate
This is a step in the right direction, but from my understanding, the populate
field is a modification that can be made on the client side, so the API would still allow unauthorized users to request email addresses if they know how to modify the request properly.
I would recommend the implementation to have a way to disable the field on the server side, but I understand that is likely a larger ask and would be happy to see either option implemented. I really appreciate you picking this up!
I agree with @Jahorse, this is also a showstopper for us.
Our case goes even further: username
and email
are the same in our database. We have an optional screenName
for users to set.
An option to set the author data would be an ideal solution.
hey hello everyone if anybody can able help me I just want to know if can I able like that comments
Hi everyone,
Just created a PR that aims to fix issues highlighted by you. Our approach is to add a configuration property that will filter out specific author
's properties.
By default all props are visible. You as a consumer of the plugin can decide which properties are too sensitive. You can even block them all.
Hi, maybe it is not right to get into this debate with this question but I dont want to create an issue. I want the other and I would like to display additionaly also verified status of the user. My users have a bool in their profile named verified being either true/false. I would like to attach this into the user object of the response along with the user avatar if possible... any solutions? 🥺
Provided in v2.2.5
Thank you for implementing this, it's working great!
Hi there, I really love your plugin, thanks for making it. I installed it on a website I have under development and it was super easy to set up and integrate.
My problem is that I don't think I can put this into production due to the API exposing user emails along with their names in unauthenticated GET requests. I believe it's likely possible to get the client side to exclude the field, but it would need to be disabled on the server to close the attack vector. It would be great if there was a setting in the admin panel to just disable that email field while still allowing the name to be returned. I'm not really sure on where I stand on the ID field, I would probably lean towards disabling it as well, but it seems like less of a concern.