JSON serializer should not support non-public properties by default

[YohDeadfall]

While working on #2192 observed that the serializer opt-ins non-public member support. At least it blocks field serialization support from behaving the same way as for properties. In worst case as @Drawaes said the issue leads to data leaks.

The issue exists starting from the first PR of JSON serializer (see #35609).

[ahsonkhan]

While working on #2192 observed that the serializer opt-ins non-public member support.

@YohDeadfall, do you have a test case that shows JSON serializer supporting non-public properties by default for some cases?

I don't believe this is a breaking change. The actual check for whether a property is public and should be supported is here:

runtime/src/libraries/System.Text.Json/src/System/Text/Json/Serialization/JsonPropertyInfoCommon.cs

Lines 48 to 58 in 89965be

	if (propertyInfo.GetMethod?.IsPublic == true)
	{
	HasGetter = true;
	Get = options.MemberAccessorStrategy.CreatePropertyGetter<TClass, TDeclaredProperty>(propertyInfo);
	}
	if (propertyInfo.SetMethod?.IsPublic == true)
	{
	HasSetter = true;
	Set = options.MemberAccessorStrategy.CreatePropertySetter<TClass, TDeclaredProperty>(propertyInfo);
	}

We only support public properties for both serialization and deserialization.

using System;
using System.Text.Json;

namespace OnlyPublicSupportedByDefault
{
    class Program
    {
        static void Main(string[] args)
        {
            var obj = new Accessor
            {
                Doing = 3
            };

            // Outputs {}
            Console.WriteLine(JsonSerializer.Serialize(obj));

            Accessor accessor = JsonSerializer.Deserialize<Accessor>("{\"Doing\": 5, \"Stuff\": \"foo\"}");

            // Outputs -1 (i.e. the default value of the property defined in the class)
            Console.WriteLine(accessor.Doing);
        }
    }

    public class Accessor
    {
        internal int Doing { get; set; } = -1;
        private string Stuff { get; set; } = "one";
    }
}

That said, we should fix the binding flags issue when getting all the properties that you identified. It shouldn't have any user facing impact though or cause the behavior to change in any way.

[YohDeadfall]

Indeed... In that case it's just a perf issue.

[YohDeadfall]

Since there is nothing to fix (the serializer doesn't support private properties), closing this. #2278 removes creation of info for non-public properties.

[YohDeadfall]

@ahsonkhan should this be listed under milestone 5.0?

[ahsonkhan]

I believe so, yes. I don't think any other milestone makes sense here and this issue was created while working on the current milestone.

[YohDeadfall]

Does it mean that to get a list all fixes and changes pull requests should be used instead? Am wondering how to determine was an issue resolved or was wrong without opening it.

[ahsonkhan]

Am wondering how to determine was an issue resolved or was wrong without opening it.

I don't know if there is a way to do this given our current labels/milestones. @danmosemsft, @karelz - what is the recommendation for filtering out issues that were "wrong" (or say "duplicate"), especially when setting the milestone/issue label? Do we need some other labels?